Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140624131244.279e6f55@vostro>
Date: Tue, 24 Jun 2014 13:12:44 +0300
From: Timo Teras <timo.teras@....fi>
To: Justin Cormack <justin@...cialbusservice.com>
Cc: musl@...ts.openwall.com
Subject: Re: getcontext etc was Re: Re: go support (was: Best
 place to discuss other lightweight libraries?)

On Tue, 24 Jun 2014 11:05:01 +0100
Justin Cormack <justin@...cialbusservice.com> wrote:

> On Jun 23, 2014 11:32 PM, "Rich Felker" <dalias@...c.org> wrote:
> > > Just to revive this post 1.0, it would be very nice indeed to have
> > > set,get,swapcontext.
> >
> > One approach to setcontext would be using rt_sigreturn, but I've
> > heard there are issues using it for setcontext involving the
> > alternate signal stack. It's the only way to do resuming _async_
> > (i.e. the ucontext received by a signal handler for the state it
> > interrupted) contexts though, so maybe there's some way to make it
> > work. This issue was discussed recently on libc-alpha (the glibc
> > list).
> 
> I am not interested in the async case not sure if other users are. If
> I read the glibc discussion correctly they are not supporting this
> any more?

I think that's intended. The whole idea of *context is to be able to do
user-space stack switching to implement co-operative threading (or
"fibers" or "green threads" or whet ever you want to call them). Being
async safe is not requirement for this.

setcontext should be fast or the whole point of it is lost. So it
should not do syscalls (signal mask twiddling).

/Timo

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.