Re: User-space threads and NSAutoreleasePool
Re: User-space threads and NSAutoreleasePool
- Subject: Re: User-space threads and NSAutoreleasePool
- From: Greg Guerin <email@hidden>
- Date: Wed, 17 Mar 2010 22:47:36 -0700
BJ Homer wrote:
I say all that in an effort to avoid the frequent "you're fighting the
frameworks" responses. I'm well familiar with the frameworks, GCD,
etc., and
in this particular case, user-space threads is what I need.
The problem is that when you call swapcontext() to switch the user-
thread
running on a kernel-thread, the NSAutoreleasePool stack is not
swapped out.
Two main questions come to mind:
Q1. What are you trying to accomplish?
Q2. Why do you think this would work?
More on Q1: You said you need user-space threads, but you gave no
reason or rationale. If it's because you need 500 threads, then why
do you need 500 threads? Exactly what are you trying to accomplish?
More on Q2: The ucontext(3) functions appear to me to be more
intended for signal-handling, specifically for alt-signal-stack
handling. The nature of signals is that they eventually return
(nested), they don't work in a round-robin or any other scheduling.
That's not a question, just prep. The question is this: Are you sure
the Objective-C runtime is compatible with ucontext user-threads?
There are lots of things you can't do in signal-handlers, not even
handlers written in plain C (ref: man sigaction, the list of safe
functions). If you can't call malloc() in a signal-handler (and I'm
pretty sure you can't), what do you expect to happen with your
Objective-C user-threads, since object allocation is tied to malloc()?
Oh, and as for "Unix heritage", the ucontext functions don't appear
until 10.5. Signal-handling with sigaction and alt-sig-stack are
older, but their limitations are equally old: AFAIK it's never been
safe to call malloc() in a signal handler.
-- GG
_______________________________________________
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