This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: swapcontext() slow
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Godmar Back <godmar at gmail dot com>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 22 Jan 2016 17:59:08 -0200
- Subject: Re: swapcontext() slow
- Authentication-results: sourceware.org; auth=none
- References: <56A0D8BA dot 6020605 at list dot ru> <20160121164016 dot GH14840 at vapier dot lan> <56A20A2E dot 4070607 at list dot ru> <56A25EDE dot 4060706 at linaro dot org> <CAB4+JYKRjo3QZUCZ_mzK6BjJsxG--=q9+mVN4ykq7yVqRL69JA at mail dot gmail dot com>
On 22-01-2016 15:24, Godmar Back wrote:
> Interesting - hadn't seen any of that.
>
> Also found this post: https://plus.google.com/+OlegZabluda/posts/KXp5i967gG4
> and http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers
> linked from there for an alternative project pursuing similar ideas of
> an almost portable interface while avoiding the sigprocmask penalty in
> swap_context.
>
> Re: Google's proposal - Turner's slide say "google proprietary" - does
> anyone know if Google runs custom kernels with this fast usermode
> scheduling facility?
>
> As one commenter on the YouTube page points out, it seems similar to
> Windows
> )
> I've always wondered which applications make use of UMS - is it just a
> facility that MS built because they thought it's cool, or do their
> core products rely on it?
>
> Related, is there interest in the Linux glibc/kernel community in
> deploying some of these ideas? (I'm not currently reading the linux
> kernel mailing list).
>
> - Godmar
>
I can't really say from kernel side what kind of interested they have on
implement M:N model in userland, but from GLIBC side we try to avoid
creating architecture or system specific ABI, specially one without
a standard.
Also, to really implement coroutines/green thread with userland with all
ISO C and POSIX bits in place one need to take in consideration a lot of
possible scenarios along with our GNU extensions (signals, TLS, threads,
blocking syscalls, etc). With this in mind you will end up with the
already existent API (swapcontext, setjmp, longjmp) or with half-baked
solutions with a set of pitfalls (such as the various libraries out there).
Another solution, which I consider better, is define the coroutines in
a strict virtual machine where the language and environment side effects
can be controlled (go, erlang, etc. for instance). In such environments
one can, for instance, create specific rule on how handle blocking syscall
or minimize the context switching by ignoring some set of registers
(if the coroutines only use a subset of available register, the environment
can just save/restore them).
One can als