Re: Patches for poll-based NSRunLoop

[Kaelin Colclasure]

On 1/26/02 2:17 AM, "Richard Frith-Macdonald" <richard@brainstorm.co.uk>
wrote:

> Can't remember if I replied to this ... please post to the bugs mailing
> list so everyone can see it, and I'll look at incorporating it into the
> source.

You did reply... I'm just having some sendmail configuration "issues" in
actually sending off the patch from the machine where I did the work.

> I think I said 'almost trivial' - but that's from the point of view
> of someone who has been writing unix comms related software since before
> either select() or poll() existed (around 20 years), and is very familiar
> with NSRunLoop ... so I guess 'straightforward' may be more appropriate.

Lol.

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?

My understanding is that only one notify-style event is fired per runloop
iteration. So, I would expect that the watcher event-handlers would
typically just queue up work for "later," not actually do significant
processing -- like invoking a nested runloop mode.

By the way, runloop modes are a really neat idea. I've been using a
runloop-like idiom for handling sockets for quite awhile, but my
implementations typically: a) were callback-based, b) fired multiple
callbacks per iteration, and c) offered no way to "go modal" short of
setting up an entirely new runloop (which I would typically do in another
thread). These characteristics all make efficient implementation somewhat
simpler, but they also lead to complicated semantics for e.g. shutting a
service down gracefully. NSRunLoop is much cleaner in this regard. Of course
it remains to be seen how efficiently it can be made to scale up. :-)

-- Kaelin