| |||||||||||||
CoroutinesCoroutinesPosted May 8, 2012 20:31 UTC (Tue) by wahern (subscriber, #37304)In reply to: Coroutines by valyala Parent article: nPth - The new GNU portable threads library
The problem with using getcontext/setcontext is that those APIs are no longer maintained, and mixing them with pthreads causes trouble. For example, on some systems thread-local-storage breaks when code trying to access a TLS object is run on a stack created with makecontext. I ran into this issue just the other day when I linked in libffi, which pulled in pthreads. (Odd, I know; but even libffi is using pthreads these days; to make its closure framework thread-safe, I believe.)
I've been writing event-oriented and thread-oriented C apps for over 13 years. Using makecontext was useful then, but not so much today.
(Log in to post comments)
Re: getcontext/setcontext alternatives Posted May 9, 2012 2:53 UTC (Wed) by scottt (subscriber, #5028) [Link] A few questions:
Re: getcontext/setcontext alternatives Posted May 9, 2012 11:20 UTC (Wed) by geertj (subscriber, #4116) [Link]
> What's the alternative to getcontext() and friends? Going back to manually
> writing per arch "stack switching" code like cgreenlet/greenlet-asm.S?
One trick that is sometimes used is sigaltstack() + setjmp(). However i would argue this is actually less portable than writing assembly (the assembly you refer to above is not OS specific, it is only architecture specific and the same function it works on Linux, Mac OSX and Windows).
In the best case, we would get a working and not-deprecated makecontext() function from libc at some point. Also we would need to get an extended longjmp() that allows for code injection in the target co-routine (for propagating exceptions in C++).
Re: getcontext/setcontext alternatives Posted May 11, 2012 23:53 UTC (Fri) by jwakely (subscriber, #60262) [Link]
Can std::current_exception and std::rethrow_exception be used for that exception propagation or are they insufficient?
|
|||||||||||||