Re: Any actor or coroutine implementations for Cocoa?
Re: Any actor or coroutine implementations for Cocoa?
- Subject: Re: Any actor or coroutine implementations for Cocoa?
- From: "Michael Ash" <email@hidden>
- Date: Tue, 29 Apr 2008 22:16:19 -0400
On Tue, Apr 29, 2008 at 8:26 PM, Jens Alfke <email@hidden> wrote:
> I completely derailed my regular project and just worked on coroutines all
> day. Here's what I've got so far.
>
> * libCoroutine does not build as-is on Mac OS X 10.5. (It's trying to
> implement its own ucontext API, which then has name collisions with the one
> that's already in the OS.)
>
> * I tweaked some #ifdefs and got libCoroutine to run, but any nontrivial
> uses of it crashed hard. Several hours later I tracked this down to what
> appears to be a bug in the system header <sys/_structs.h>. Fortunately it
> was easy to work around. (I've posted a message to the darwin-userlevel
> mailing list asking about this.)
>
> * Since I was already modifying libCoroutine, and since 90% of its code is
> just for cross-platform compatibility, I tweezed out just the part that's
> necessary for Mac OS X and made my own "CoroX.c". It's only 150 lines of
> code. I can actually read it and understand what it's doing. (I've kept
> Steve's copyright notice and made it clear this is a derivative work.)
>
> * Then I wrote an Objective-C API around it. Only 140 lines. Here's the
> header:
>
> http://mooseyard.com/hg/hgwebdir.cgi/Actors/file/tip/Coroutines/MYCoroutine.h
>
> * Finally I put this into a Mercurial repository and hosted it on my
> website:
> http://mooseyard.com/hg/hgwebdir.cgi/Actors/
> If you use Mercurial, you can just clone from the above URL to get a local
> repo. If you don't, you can use the "files" or "zip" links on that web page
> to browse or download the code.
>
> Next I'd like to implement a simpler "generator" style API (where a
> coroutine calls "yield" to return a value to its caller) since that's easier
> for me to get my head around than the general model where every coroutine
> chooses which one to run next. From there, actors shouldn't be too hard to
> do.
>
> One potential problem is the interaction with Cocoa features that
> implicitly rely on the stack: exceptions and autorelease pools. I suspect
> that coroutines will confuse both of those.
I once experimented with coroutines in Cocoa with the goal of turning
asynchronous methods with callbacks (such as the sheet methods) into
synchronous methods. (I should note that I didn't write the coroutines
library, I just played with one that somebody else put together.)
There were a lot of problems with Cocoa and returning to the runloop
without returning back the way I came. Exceptions and autorelease
pools were two of them, although they were easy enough to fix by
manually swapping out the private NSThread ivars. A bigger problem was
handling stuff like menu and button highlighting; they highlight when
you click, and unhighlight when your code returns back to them. With
coroutines this assumption is blown away and things start to fall down
badly.
You could probably do fairly well if you avoid using them on the main
thread. You'll still have to do a bit of evil but not as much, and I
think it's all reasonable to work around. For this sort of actor stuff
it may be entirely reasonable to proxy out to a secondary thread which
contains the coroutines so you don't mess with the main thread like I
was doing.
Mike
_______________________________________________
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