On Thu, 9 Aug 2012 16:32:20 +0000 Emmanuel Dreyfus <manu@xxxxxxxxxx> wrote: > The patch sets SYNCENV_PROC_MAX to 1 for NetBSD. If I understand > correctly, that address the problem raised here: there is only one > thread in a syncenv. Did I get it wrong? That could be considered an extreme form of enforcing task/thread affinity, and thus it would avoid the scenario we were discussing, but it also precludes getting any kind of parallelism through the syncop subsystem. I'd rather see an approach that enforces task/thread affinity (on platforms that need it) but still allows multiple tasks to run in parallel (on any platform). Then again, if this is sufficient for your needs, perhaps we should just merge the patch and not worry about parallelism unless/until someone on a similar platform expresses a need for it. > I asked about the issue on tech-kern@xxxxxxxxxx. I get a first reply > suggesting thet setjmp()/longjmp() would be better suited than > swapcontext() for that job. Any opinions? I don't think setjmp/longjmp provide an adequate alternative, since we really do need separate stacks which are preserved across arbitrarily many task transitions. As soon as you do a longjmp, you start destroying the stack from before. That's OK for implementing exceptions, but not for "green threads" or continuations. That's kind of why the ucontext calls were created, even though setjmp/longjmp already existed at the time.
