Re: Patches for poll-based NSRunLoop

[Kaelin Colclasure]

On 1/26/02 3:03 PM, "Richard Frith-Macdonald" <richard@brainstorm.co.uk>
wrote:

> 
> On Saturday, January 26, 2002, at 10:50 PM, Kaelin Colclasure wrote:
> 
>> So here is a question I have which you might be able to answer quickly:
>> The
>> implementation implies that -acceptInputForMode:beforeDate: must be
>> reentrant. Why? Is this so that e.g. NSPorts can implement "transparent"
>> event handling or something?
> 
> Well, it's needed for any event handler which might run the runloop
> again internally before returning, but in particular it's for the
> distributed objects system.

This is just what I'd guessed. :-)

> Say a client sends a message to a server passing a proxy to one of the
> objects
> in the client the server sends a request to that proxy for information,
> and
> the client must then send a response to that ... all while waiting for
> the
> response to the original request.

Hmmm. Obviously the optimization I am poking around at is the ability to
allocate the array of pollfds once per runloop, rather than for each runloop
iteration. My ideal would be that everything grows dynamically to
accommodate as many e.g. file descriptors as needed, but that "on average"
no memory is ever allocated or freed by the "inner loop" of a runloop. [The
select-based implementation benefits from the fact that FD_SET is fixed in
size and small enough to allocate on the stack.]

This is still achievable in principle, but complicated (and slowed) by the
requirement for reentrancy. I can't help but think that it might be possible
to have watcher event handlers behave more like notification-style event
handlers, but there is no doubt a performance penalty there too. Although
arguably a small savings in each runloop iteration would offset a fairly
substantial penalty in DO system event handing...

BUT until performance actually proves to be an issue, I don't really have
cycles to throw away on this anyway. Just curiosity for the moment. ;-)

-- Kaelin