[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patches for poll-based NSRunLoop
From: |
Kaelin Colclasure |
Subject: |
Re: Patches for poll-based NSRunLoop |
Date: |
Sat, 26 Jan 2002 14:50:46 -0800 |
User-agent: |
Microsoft-Entourage/10.0.0.1309 |
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