[Gluster-devel] NetBSD swapcontext() portability fix

[Jeff Darcy]

On Thu, 9 Aug 2012 16:32:20 +0000
Emmanuel Dreyfus <manu at netbsd.org> 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 at netbsd.org. 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.