Re: Questions about [NSApplication run]
Re: Questions about [NSApplication run]
- Subject: Re: Questions about [NSApplication run]
- From: Ken Thomases <email@hidden>
- Date: Fri, 5 Dec 2008 22:41:45 -0600
On Dec 5, 2008, at 10:03 PM, Slava Pestov wrote:
The reason I'm doing it is because I have a Cocoa binding for Factor
(http://factocode.org), and the Factor VM doesn't support native
threads. The language has its own lightweight co-operative thread
model, with all I/O done non-blocking under the hood, to give the
illusion of concurrency; a lightweight thread yields to to other
lightweight theads when waiting for I/O.
This means I have to wait for Cocoa events and call select() from the
same event loop. To do this, I have a really horrible hack: as long as
no lightweight threads are ready to run, I poll for Cocoa events,
dispatch them, then wait up to 10ms for I/O by calling select() on all
active file descriptors, then the loop repeats.
I believe Squeak Smalltalk does something similar, but I'd really like
to find a better way, since the polling is inefficient.
While I do plan on making the VM native thread-safe eventually, for
now an ideal fix would be to either find a way to add a kqueue as a
run loop event source, or add the run loop to a kqueue.
Has anyone ever done anything like this?
If you can require Leopard, take a look at CFFileDescriptor. Prior to
Leopard, you can use CFSocket with any file descriptor, so long as you
don't use the socket-specific parts of that interface.
Replacing select() is exactly what run-loops are for.
If you use -nextEventMatchingMask:untilDate:inMode:dequeue: and have
also installed CFFileDescriptors on the run-loop, and you need to
break out of -nextEvent... when one of those file descriptors fires,
you can post a custom event (of type NSApplicationDefined) from the
file descriptor callback. In that way, you don't have to provide an
artificially short timeout -- you can avoid the polling.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden