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 (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

Reply via email to