On Wed, Mar 17, 2010 at 11:11 PM, BJ Homer <bjho...@gmail.com> wrote: > Okay, so that's the setup. Obviously, the problem is that the two user-space > threads are sharing an autorelease pool stack that is intended to be > thread-local. My question, then, is whether there exists a way to get and > set the autorelease pool stack, so that before calling swapcontext(), I > could put it in a state appropriate for this user-level thread? I assume it > is being stored in thread-local storage, but it's not in the NSThread > threadDictionary, which means it's probably set using pthread_setspecific. > Accessing that value would require the key used to store it, but naturally I > don't have access to that. So is there some existing function call that > allows such access?
I did some experimenting with this sort of thing back in the 10.4 days, using custom userspace threading code (but it should be pretty much the same as this library call). I came to the conclusion that it was impractical. Cocoa keeps around a lot of thread-specific state. In addition to autorelease pools, you also have exception handlers, graphics contexts, and possibly others. You also have implicit thread-specific state like runloops and various non-reentrant code that may be calling yours when you switch to another user-level thread. And Cocoa assumes on a pretty deep level that the only threading you're doing is pthreads, and things built on top of pthreads like NSThread. In short, I think you're doomed. Any code you call in your user-level threads needs to be minimally aware of them and compatible with them (at least to the extent of not assuming pthreads), so you can't just call arbitrary libraries. I'm afraid Cocoa falls into that category. Since you mention in another message that this is portable, cross-platform code, why do you need to call Cocoa from the user-level threads at all? Separate your code into cross-platform code that does this swapcontext stuff, and Mac-specific code that doesn't, and you should be good. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
