On Mon, May 9, 2016 at 12:35 PM, Rich Felker <dal...@libc.org> wrote: > On Mon, May 09, 2016 at 09:02:33PM +0200, Michael Matz wrote: >> Hi, >> >> On Sat, 7 May 2016, Rich Felker wrote: >> >> > > > * sigaltstack and swapcontext are broken too. >> > > >> > > We have prototype that supports swapcontext that we're happy to >> > > release, but it clearly requires more work before being ready to merge >> > > upstream. >> > >> > The *context APIs are deprecated and I'm not sure they're worth >> > supporting with this. It would be a good excuse to get people to stop >> > using them. >> >> How? POSIX decided to remove the facilities without any adequate >> replacement (thread aren't). > > Threads work just as well as the ucontext api for coroutines. Due to > the requirement to save/restore signal masks, the latter requires a > syscall, making it no faster than a voluntary context switch via > futex syscall.
No, threads do not work as well. You can not ignore efficiency considerations. Coroutine switching is much faster with setcontext, even though it does a system call. > Most of the other hacks people used the ucontext API for were complete > hacks with undefined behavior, anyway. And yet code like gccgo's library works, on many different systems. > BTW it's not even possible to implement makecontext on most targets > due to the wacky variadic calling convention it uses -- in most ABIs, > there's simply no way to shift the variadic args into the right slots > for calling the start function for the new context without knowing > their types, and the implementation has no way to know the types. So > it's really an unusably broken API. I certainly agree that makecontext is broken by design. But it is easy enough, and safe, to use makecontext with functions that take no arguments. I would fully support an effort to propagate a replacement for makecontext that can actually work more generally. I think the current approach of simply dropping support is unwise. Ian
