setcontext/getcontext/makecontext missing?

setcontext/getcontext/makecontext missing?

[Short, Todd]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

Hi,

It appears that setcontext/getcontext/makecontext are declared in ./include/ucontext.h, but there’s no definitions for them in musl. These three functions are part of libc/glibc.so:

GLIBC_2.0 setcontext
GLIBC_2.1 getcontext
GLIBC_2.1 makecontext

Since the functions are declared, is there any intent to put them into musl?

I ran into this when attempting to compile OpenSSL with musl. In the OpenSSL master branch, I’m able to do:

CC=musl-gcc ./config
make depend
make

However, ld fails because there is an undefined reference to setcontext, getcontext and makecontext. This is new async functionality in OpenSSL that uses these APIS.

This is as of musl:master:47314f1 and openssl:master:4c35c93


Thanks,

--
-Todd Short
// tshort@akamai.com<mailto:tshort@akamai.com>
// "One if by land, two if by sea, three if by the Internet."


[-- Attachment #2: Type: text/html, Size: 2541 bytes --]

Re: setcontext/getcontext/makecontext missing?

[Szabolcs Nagy]

* Short, Todd <tshort@akamai.com> [2016-02-04 14:09:30 +0000]:
> 
> It appears that setcontext/getcontext/makecontext are declared in ./include/ucontext.h, but there???s no definitions for them in musl. These three functions are part of libc/glibc.so:
> 

these are deprecated posix apis.

> Since the functions are declared, is there any intent to put them into musl?
> 

they have unclear semantics and only possible to
implement in asm (hence it is a significant effort
to add them).

> I ran into this when attempting to compile OpenSSL with musl. In the OpenSSL master branch, I???m able to do:
> 
> CC=musl-gcc ./config
> make depend
> make
> 
> However, ld fails because there is an undefined reference to setcontext, getcontext and makecontext. This is new async functionality in OpenSSL that uses these APIS.
> 

imho that's an openssl bug.

if they really need the *context apis, then use adequate
(link-time) configure check for them.

but looking at
http://git.openssl.org/?p=openssl.git;a=commit;h=a3667c316ae60ef454fb804221c3ca44af30a9aa
this async lib is probably misguided, but they can
implement the api with pthreads in a portable way.

> This is as of musl:master:47314f1 and openssl:master:4c35c93
> 
> 
> Thanks,
> 
> --
> -Todd Short
> // tshort@akamai.com<mailto:tshort@akamai.com>
> // "One if by land, two if by sea, three if by the Internet."
> 

Re: setcontext/getcontext/makecontext missing?

[Rich Felker]

On Thu, Feb 04, 2016 at 03:54:09PM +0100, Szabolcs Nagy wrote:
> * Short, Todd <tshort@akamai.com> [2016-02-04 14:09:30 +0000]:
> > 
> > It appears that setcontext/getcontext/makecontext are declared in
> > ./include/ucontext.h, but there???s no definitions for them in
> > musl. These three functions are part of libc/glibc.so:
> > 
> 
> these are deprecated posix apis.
> 
> > Since the functions are declared, is there any intent to put them into musl?
> > 
> 
> they have unclear semantics and only possible to
> implement in asm (hence it is a significant effort
> to add them).

There's been some interest in adding them and they were on a long-term
goal list, but I'm not sure it makes sense anymore. All the major
users of this API have been moving _off_ of it, because it's
deprecated and impossible to use correctly - see the rationale here:

http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html

So it's rather unfortunate (but typical OpenSSL nonsense) that they've
adding a new use of it.

> > I ran into this when attempting to compile OpenSSL with musl. In
> > the OpenSSL master branch, I???m able to do:
> > 
> > CC=musl-gcc ./config
> > make depend
> > make
> > 
> > However, ld fails because there is an undefined reference to
> > setcontext, getcontext and makecontext. This is new async
> > functionality in OpenSSL that uses these APIS.
> > 
> 
> imho that's an openssl bug.
> 
> if they really need the *context apis, then use adequate
> (link-time) configure check for them.

Agree strongly. There's at least one other major POSIX/POSIX-like
system that lacks them.

> but looking at
> http://git.openssl.org/?p=openssl.git;a=commit;h=a3667c316ae60ef454fb804221c3ca44af30a9aa
> this async lib is probably misguided, but they can
> implement the api with pthreads in a portable way.

Indeed.

Rich

Re: setcontext/getcontext/makecontext missing?

[u-uy74]

On Thu, Feb 04, 2016 at 10:41:38AM -0500, Rich Felker wrote:
> There's been some interest in adding them and they were on a long-term
> goal list, but I'm not sure it makes sense anymore. All the major
> users of this API have been moving _off_ of it, because it's
> deprecated and impossible to use correctly - see the rationale here:
> 
> http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html

Just for the record, nevertheless it is a pity to lose them.

In my experience the ucontext-based implementation of user-space threads
suits/works best for Coda file system, even though Coda can use an
alternative pthread-based implementation of the needed threading layer.

Pthreads feels like an overkill, hardly efficient when all one needs
is cooperative threading designed from the beginning to fit in one
process.

Still this probably does not justify putting effort in adding this
(apparently non-compliant) API to musl. Sigh.

Regards,
Rune

Re: setcontext/getcontext/makecontext missing?

[Szabolcs Nagy]

* u-uy74@aetey.se <u-uy74@aetey.se> [2016-02-04 17:22:47 +0100]:
> On Thu, Feb 04, 2016 at 10:41:38AM -0500, Rich Felker wrote:
> > There's been some interest in adding them and they were on a long-term
> > goal list, but I'm not sure it makes sense anymore. All the major
> > users of this API have been moving _off_ of it, because it's
> > deprecated and impossible to use correctly - see the rationale here:
> > 
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
> 
> Just for the record, nevertheless it is a pity to lose them.
> 

note that the broken makecontext prototype is not the
only reason these apis are problematic:

- getcontext can return more than once (like setjmp and vfork,
this means the compiler has to recognize getcontext calls by
name and generate code more carefully around it, so if you
call it through a different name or function pointer that's
broken: local variables may get arbitrarily clobbered).
the magic names gcc knows about:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/calls.c;h=8f573b83430c52955e215e7aabcdb55cb3a76d6a;hb=HEAD#l532

- the ucontext struct passed to *context apis is not the same
as the ucontext passed to signal handlers by the kernel, but
confusingly they use the same type.
(the spec originally wanted this to work but the libc has no way
to know the kernel ucontext abi which is expanding due to new cpu
state in newer cpus.  implementations tried to fiddle with the
sigreturn syscall mechanism to make this work, but that is
problematic with sigaltstack.. e.g.
https://sourceware.org/ml/libc-alpha/2014-04/msg00006.html
so kernel and userspace ucontext cannot be mixed.)

- there was an other issue in the spec if setcontext exits the
main thread (it was not clear what cleanups will be performed).
https://sourceware.org/ml/libc-alpha/2015-03/msg00556.html

- userspace scheduling of execution threads have various issues
in general because they cannot be preemptively scheduled.
(computation loops without scheduling points can starve or
livelock the system, cooperative threads is not an easy to use
programming model. this affect all green thread runtimes from
go to erlang which indeed are usually used for io intensive
workloads not computation loops.)

> In my experience the ucontext-based implementation of user-space threads
> suits/works best for Coda file system, even though Coda can use an
> alternative pthread-based implementation of the needed threading layer.
> 
> Pthreads feels like an overkill, hardly efficient when all one needs
> is cooperative threading designed from the beginning to fit in one
> process.
> 
> Still this probably does not justify putting effort in adding this
> (apparently non-compliant) API to musl. Sigh.
> 
> Regards,
> Rune

Re: setcontext/getcontext/makecontext missing?

[Rich Felker]

On Thu, Feb 04, 2016 at 05:22:47PM +0100, u-uy74@aetey.se wrote:
> On Thu, Feb 04, 2016 at 10:41:38AM -0500, Rich Felker wrote:
> > There's been some interest in adding them and they were on a long-term
> > goal list, but I'm not sure it makes sense anymore. All the major
> > users of this API have been moving _off_ of it, because it's
> > deprecated and impossible to use correctly - see the rationale here:
> > 
> > http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
> 
> Just for the record, nevertheless it is a pity to lose them.
> 
> In my experience the ucontext-based implementation of user-space threads
> suits/works best for Coda file system, even though Coda can use an
> alternative pthread-based implementation of the needed threading layer.
> 
> Pthreads feels like an overkill, hardly efficient when all one needs
> is cooperative threading designed from the beginning to fit in one
> process.

In theory, userspace context switching could possibly be slightly
faster than threads. However the ucontext API saves/restores the
signal mask as part of context switching, which inherently requires a
syscall. (There are possibly ways we could cache the most-recently-set
signal mask in TLS and avoid redundant setting, but no existing libcs
do this, and it sounds mildly difficult/error-prone.) Thus the
comparison is not between pure-userspace switching and having the
kernel involved, but between a SYS_rt_sigprocmask syscall and a
voluntary context switch between threads in the same process. The
latter is extremely light and comparable to some of the cheapest
syscalls, so I suspect the performance difference between ucontext and
threads is negligible. Given that there are a lot of other good
reasons you should be using threads instead of ucontext, I think the
matter is pretty clear.

Rich

Re: setcontext/getcontext/makecontext missing?

[u-uy74]

On Thu, Feb 04, 2016 at 06:01:32PM +0100, Szabolcs Nagy wrote:
> * u-uy74@aetey.se <u-uy74@aetey.se> [2016-02-04 17:22:47 +0100]:
> > On Thu, Feb 04, 2016 at 10:41:38AM -0500, Rich Felker wrote:
> > > http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html
> > 
> > Just for the record, nevertheless it is a pity to lose them.
> 
> note that the broken makecontext prototype is not the
> only reason these apis are problematic:

Thanks for the detailed explanation Szabolcs.

I was aware of most of the general issues/limitations but good to know
in depth.

Regards,
Rune

Re: setcontext/getcontext/makecontext missing?

[u-uy74]

On Thu, Feb 04, 2016 at 02:24:03PM -0500, Rich Felker wrote:
> > Pthreads feels like an overkill, hardly efficient when all one needs
> > is cooperative threading designed from the beginning to fit in one
> > process.

> the comparison is not between pure-userspace switching and having the
> kernel involved, but between a SYS_rt_sigprocmask syscall and a
> voluntary context switch between threads in the same process. The
> latter is extremely light and comparable to some of the cheapest
> syscalls, so I suspect the performance difference between ucontext and
> threads is negligible.

Thanks for pointing this out, if rt_sigprocmask can not be skipped
then indeed a switch becomes much more expensive.

> Given that there are a lot of other good
> reasons you should be using threads instead of ucontext, I think the
> matter is pretty clear.

Sure, the API was not exactly well thought-out.
Still I'd like to have a lighweight choice when it is enough.
This is of course offtopic for musl, given that there is no reasonable
standard/specification for the purpose.

Regards,
Rune

Re: setcontext/getcontext/makecontext missing?

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On 5 Feb 2016 1:59 am, <u-uy74@aetey.se> wrote:
>
> On Thu, Feb 04, 2016 at 02:24:03PM -0500, Rich Felker wrote:
> > > Pthreads feels like an overkill, hardly efficient when all one needs
> > > is cooperative threading designed from the beginning to fit in one
> > > process.
>
> > the comparison is not between pure-userspace switching and having the
> > kernel involved, but between a SYS_rt_sigprocmask syscall and a
> > voluntary context switch between threads in the same process. The
> > latter is extremely light and comparable to some of the cheapest
> > syscalls, so I suspect the performance difference between ucontext and
> > threads is negligible.
>
> Thanks for pointing this out, if rt_sigprocmask can not be skipped
> then indeed a switch becomes much more expensive.

Many users of this interface do not actually require this. Actually NetBSD
makes the context functions syscalls themselves. And OpenBSD does not
provide them at all.

I have taken to just including implementations (without the signal calls)
in code that needs to use them, with modifications to fix the prototype
issues as most code only needs to pass a single argument. At one point I
was going to do implementations for Musl but I think it is a bad idea.

> > Given that there are a lot of other good
> > reasons you should be using threads instead of ucontext, I think the
> > matter is pretty clear.
>
> Sure, the API was not exactly well thought-out.
> Still I'd like to have a lighweight choice when it is enough.
> This is of course offtopic for musl, given that there is no reasonable
> standard/specification for the purpose.
>
> Regards,
> Rune
>

[-- Attachment #2: Type: text/html, Size: 2030 bytes --]

Re: setcontext/getcontext/makecontext missing?

[u-uy74]

On Sat, Feb 06, 2016 at 09:20:49PM -0800, Justin Cormack wrote:
> > Thanks for pointing this out, if rt_sigprocmask can not be skipped
> > then indeed a switch becomes much more expensive.
> 
> Many users of this interface do not actually require this. Actually NetBSD
> makes the context functions syscalls themselves. And OpenBSD does not
> provide them at all.
> 
> I have taken to just including implementations (without the signal calls)
> in code that needs to use them

That's what Coda does.
This creates the burden to add the assembler code for new architectures
when necessary - or an option to resort to one of the heavier alternatives.

> with modifications to fix the prototype
> issues as most code only needs to pass a single argument. At one point I
> was going to do implementations for Musl but I think it is a bad idea.

I have to agree. Providing a non-compliant implementation in musl
would undermine its spirit (of standard-compliance).

OTOH a tiny standalone library with the adjusted API and without the
signal stuff *might* be actually a good fit for some applications,
especially for the old ones written to ucontext.

Rune