Hi, 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? Slava On Fri, Dec 5, 2008 at 4:51 PM, Michael Ash <[EMAIL PROTECTED]> wrote: > I'm afraid I don't know the answer to your question, but can I ask why > you're doing this in the first place? If you just need to run some > custom code every time through the event loop, > NSApplicationDidUpdateNotification or CFRunLoopObserver will do it for > you. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
