I was wondering about the parameters of two APIs of epoll.
epoll_create (int size) - in this API, size is defined as the size of event pool. But, it seems that having more events than the size still works. (I've put the size as 2 and forced event pool to have 3 events... but it still works !?) Thus I was wondering what this parameter actually means and curious about the maximum value of this parameter.
epoll_wait (int maxevents) - for this API, the maxevents definition is straight-forward. However, I can see the lackness of information or advices on how to determin this parameter. I expect this parameter to be changed depending on the size of epoll event pool size. Any suggestions or advices will be great. Thank you!
1.
"man epoll_create"
DESCRIPTION
...
The size is not the maximum size of the backing store but just a hint
to the kernel about how to dimension internal structures. (Nowadays,
size is unused; see NOTES below.)
NOTES
Since Linux 2.6.8, the size argument is unused, but must be greater
than zero. (The kernel dynamically sizes the required data struc‐
tures without needing this initial hint.)
2.
Just determine an accurate number by yourself, but be aware that
giving it a small number may drop out the efficiency a little bit.
Because the smaller number assigned to "maxevent" , the more often you may have to call epoll_wait() to consume all the events, queued already on the epoll.
Related
why stack pointer is initialized to the maximum value?
I only knows that It is the tiny register which stores the last program request’s address in a stack. It is the particular kind of buffer that stores the information in the order of top-down. but can anyone explain me why initially it's having max value.
Without more detail on the actual microprocessor, there isn't a single exact answer; but in general, each architecture handles stack pointer initialization a bit differently. For example, the version of ARM used in many microprocessors initializes the stack pointer (also R13) from the vector table (the first entry). Other architectures either initialize the register to 0 or some other value; so it's not always all 1s as you mention in your question. If the hardware itself doesn't initialize the stack pointer so somewhere meaningful, some of the first instructions usually does. And usually this value is near or at the top of memory as you mention, the stack typically grows down from higher addresses to lower ones; so a value of all 1s or some other larger value might make sense depending on how memory is laid out and managed.
One thing also worth mentioning is that you say the stack stores the "last program request's address" which if I understand correctly is one of the things the stack stores. In more architectures, the stack can store much more than just the return address of a call but also local variables, saved context when a call is made or a context is swapped (either by an OS or by an exception/interrupt) and anything else the program might want to push onto it.
So the short answer is: it isn't always set to the maximum value but it's usually set to some high value as the stack will grow down to lower addresses as things like data and addresses are pushed on it.
I'm working on a practice final exam and I can't seem to figure out the answer to this question.
My understanding is that every initial page being brought in counts as a page fault, so even without the address lengths, this question should be false, correct? If we forget about this for a second, is the answer true? My thought behind this is that since the logical address only has 24 bits while the physical address has 32 bits, there would never be a case where the page has to be in a frame that is already occupied. Is more information required (such as page size) for this realm of reasoning?
every initial page being brought in counts as a page fault
Just as a note, this is true only if you create the process (populate the PCB, process control block) but you don't actually assign any frame. The first (and some of the other) reference (basically, the first istruction) will generate a page fault.
This is why you (you as the OS) have to assign a sufficent number of frame to avoid early page fault (and, with a pinch of luck and a good pager, even later in the execution of the process).
Back at your question: the answer is false (depends is more correct).
The reason is simple: if you don't know the size of the memory, you can't actually know how many frame do you have at hand. So the address size is totally useless in this specific context.
I know that, for a list, we have to traverse the entire list and then determine the size of it?
What is the complexity to determine the size of a binary in Erlang?
byte_size/1 (the command to measure binary stuff) executes in constant time irrelevant to the size of the binary, while length of a list is proportional to the size of the list.
See 3 Common Caveats for reference
Time and memory complexity of erlang:size/1, erlang:tuple_size/1, erlang:bit_size/1 and erlang:byte_size/1 is O(1). (And erlang:map_size/1 as well.) Why do you even think it could be anything else? It doesn't make any sense.
I mean what's the max width and height the function support, thanks!
I tried two times height of the screen, report an error 0x8cdd which means not support.
When in doubt, always read the extension specification... in this case: GL_APPLE_framebuffer_multisample.
If you read the extension specification, it points you to GL_MAX_RENDERBUFFER_SIZE and an additional implementation-defined limit specific to the extension itself: GL_MAX_SAMPLES_APPLE.
In short, width and height cannot exceed the value of GL_MAX_RENDERBUFFER_SIZE and the number of samples cannot exceed GL_MAX_SAMPLES_APPLE. So you should query these values at run-time and act accordingly.
GLuint max_rb_size, max_samples_apple;
glGetIntegerv (GL_MAX_RENDERBUFFER_SIZE, &max_rb_size);
glGetIntegerv (GL_MAX_SAMPLES_APPLE, &max_samples_apple);
This ought to answer your question, since this is implementation specific this is the best I can do for you. I could tell you that GLES2 requires MAX_RENDERBUFFER_SIZE to be at least 1x1 (no joke), and Apple's extension only requires 1 sample to be supported. Neither one of these required minimum values is particularly useful so you will have to query it at run-time to find out what a real system supports :)
OpenGL ES 2.0.25 Specification - 6.2. State Tables - pp. 154
Considere I have a CFMutableArray object created with the following function call:
CFMutableArrayRef marray = CFArrayCreateMutable(kCFAllocatorDefault, 1, &kCFTypeArrayCallBacks);
According to the CFMutableArray Documentation, the second argument of CFArrayCreateMutable, which is called capacity, is "the maximum number of values that can be contained by the new array. The array starts empty and can grow to this number of values (and it can have less).
Pass 0 to specify that the maximum capacity is not limited. The value must not be negative."
However, if I append more than one value to my new array, it keeps growing. I mean, if the new array already has one value and I append a new one with CFArrayAppendValue(marray, newValue), this value is stored and the array count goes to 2, exceeding its capacity.
So, why this happens? Did I misunderstand the documentation?
Interesting. I don't think you're mis-understanding the documentation. I will point out that CFMutableArrayRef is "Toll Free Bridged" on iOS with NSMutableArray and therefore interchangeable. On iOS [NSMutableArray arrayWithCapacity] is NOT so limited and capacity is basically "guidance" and NOT a hard upper limit.
It might be worth filing a bug report on that, probably the docs are just wrong.
UPDATE: Just goes to show ya... always, always, always follow the maxim of the best docs are the source. I CMD-clicked on CFArrayCreateMutable to look at the comment in the source .h file.... guess I was right, because that says 'capacity' is a HINT that the implementation may ignore, as it apparently does in this case.
#function CFArrayCreateMutable
⋮
#param capacity A hint about the number of values that will be held by the CFArray.
Pass 0 for no hint. The implementation may ignore this hint,** or may use it to
optimize various operations. An array's actual capacity is only limited by
address space and available memory constraints). If this parameter is negative,
the behavior is undefined.
Don't forget, header comments are written by developers, whilst "docs" are written by some tech writer that doesn't have the same depth of knowledge.
From docs:
CFArrayAppendValue
Adds a value to an array giving it the new largest index.
Parameters
theArray
The array to which value is to be added. If theArray is a limited-capacity array and it is full before this operation, the behavior is undefined.
So, I think you should only make sure not to add a value to a full limited-capacity array, or the behavior will be undefined!
Or, you can pass 0 for the capacity parameter to specify that the maximum capacity is not limited.
Update:
As #Cliff Ribaudo pointed out, it seems there is a contradiction between the official documentation and code documentation:
#param capacity A hint about the number of values that will be held
by the CFArray. Pass 0 for no hint. The implementation may
ignore this hint, or may use it to optimize various
operations. An array's actual capacity is only limited by
address space and available memory constraints).
So we can assume the online documentation is outdated and the code documentation is possibly the right.