I've finally gotten around to updating this branch. As part of this, I
refactored the code for generating signals so that it is reusable
across different 2LSs (previously it was written specifically for the
pthread scheduler). Now, both the pthread scheduler and our simple
thread0 scheduler have built-in support for standard posix signals,
and it is straightforward (it only takes two strategically placed
commands) to add support to any future schedulers.
As part of this, I also updated the code to allow a signal handler to
continue running on the stack of whatever thread it is interrupting. I
also push the saved user context (and any other ancillary state it
needs to save) onto this stack before running the signal handler.
Previously, I had been allocating space for this on the side, so it
had to be cleaned up once the signal handler completed. With these
changes, Davide should now be able to do his longjmp calls from within
a signal handler without repercussions.
Finally, I used this new setup to implement proper SIGPIPE support in
user-space. The kernel always returns EPIPE in cases where there is a
write after all readers have closed, and user-space takes care of
generating the SIGPIPE signal on the current thread if necessary. With
the new way the code has been refactored, adding this new
functionality was trivial.
Rebuild your cross compiler!
The changes in this request can be viewed online at:
https://github.com/brho/akaros/compare/a759dfd...adf81cf
The following changes since commit a759dfde3f64ecc4e7f84d074ed69900445ede85:
Migrated position dependent initialization, to label based
(2015-11-10 11:43:08 -0500)
are available in the git repository at:
[email protected]:klueska/akaros sigpipe-support
for you to fetch changes up to adf81cfb9ae150a0e1b0202aeb6c76f38ab1f0f8:
Add support for EPIPE and SIGPIPE (XCC) (2015-11-11 00:55:00 -0800)
----------------------------------------------------------------
Kevin Klues (11):
Fix bug in pthread_sigmask() semantics.
Add parlib-compat.c for weak symbols with parlib
Weasel apart parlib/libc symbols for signals (XCC)
Add arch independent accessor for user ctx stack
Remove need for externally alloced sigdata struct
Encapsulate pthread sigstate into a single struct
Add uthread_paused() API call
Migrate signal code from pthread.c to signal.c
Add signal support to our basic thread0 scheduler
Add a sigself() signal_op
Add support for EPIPE and SIGPIPE (XCC)
kern/drivers/dev/pipe.c | 5 +-
.../glibc-2.19-akaros/sysdeps/akaros/Makefile | 5 +
.../glibc-2.19-akaros/sysdeps/akaros/Versions | 6 +
.../sysdeps/akaros/parlib-compat.c | 28 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigaction.c | 166 ++++++++
.../glibc-2.19-akaros/sysdeps/akaros/sigaltstack.c | 27 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigintr.c | 28 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigpending.c | 28 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigprocmask.c | 30 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigqueue.c | 28 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigreturn.c | 26 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigstack.c | 27 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigsuspend.c | 32 ++
.../sysdeps/akaros/sigtimedwait.c | 29 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigwait.c | 28 ++
.../glibc-2.19-akaros/sysdeps/akaros/sigwaitinfo.c | 28 ++
.../glibc-2.19-akaros/sysdeps/akaros/write.c | 22 +-
user/parlib/include/parlib.h | 18 -
user/parlib/include/riscv/vcore.h | 5 +
user/parlib/include/signal.h | 61 +++
user/parlib/include/uthread.h | 3 +
user/parlib/include/x86/vcore32.h | 5 +
user/parlib/include/x86/vcore64.h | 5 +
user/parlib/signal.c | 458 ++++++++++-----------
user/parlib/thread0_sched.c | 3 +
user/parlib/uthread.c | 18 +
user/pthread/pthread.c | 193 +--------
user/pthread/pthread.h | 4 +-
28 files changed, 872 insertions(+), 444 deletions(-)
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/parlib-compat.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigaction.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigaltstack.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigintr.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigpending.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigprocmask.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigqueue.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigreturn.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigstack.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigsuspend.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigtimedwait.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigwait.c
create mode 100644
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/sigwaitinfo.c
create mode 100644 user/parlib/include/signal.h
On Tue, Nov 3, 2015 at 12:11 PM, Barret Rhoden <[email protected]> wrote:
> On 2015-10-30 at 17:32 Kevin Klues <[email protected]> wrote:
>> >> + /* Ensures signals we just unmasked get processed if they
>> >> are pending */
>> >> + sched_yield();
>> >
>> > Does this actually work? In the pthread side, the signals are in
>> > the pending set. On the default 2LS side, I think if they aren't
>> > fireably immediately, they get ignored.
>>
>> I was thinking about this as I wrote it, and decided to just put it in
>> because it was symmetrical with the pthread implementation. It's
>> probably OK to take it out, as it probably does nothing. It does
>> actually work though if you're asking about it continuing to run after
>> this point.
>
> As far as "actually work" goes, I meant would it force the reception of
> blocked signals, which I think won't happen.
>
>> That was the idea. We need a way of stalling the current uthread and
>> generating a signal in its place before allowing the uthread to
>> continue (if it ever continues at all). In the pthread world, this
>> would have simply been a pthread_kill(pthread_self(), SIGPIPE)
>> followed by a pthread_yield(). However, I needed a way to make this
>> work for non-pthread code. Anyway, we can't call any parlib/pthread
>> code from within the write() call because of link errors when build
>> rtld.
>
> Yeah, it's a mess.
>
>> >> - nexterror();
>> >> + poperror();
>> >> + error(EPIPE, NULL);
>> >
>> > This style is a little weird. A lot of times in Plan 9, they just
>> > set_errstr and call error. Either is okay. The problem here is
>> > that errstr is now gone. If you want to keep errstr, you could
>> > set_errno to EPIPE, then call nexterror.
>>
>> Yeah, I've never gotten comfortable with the waserror() stuff in
>> general. If that's the preferred way, then I'll do it that way.
>
> It's not a huge deal either way - more of a "what do you want to do
> here". As written, it'll do what you want, but it'll clobber errstr.
> I was mostly trying to let you know that it's totally fine to just
> change errno or errstr on its own and then call nexterror().
>
>> > This probably won't compile on recent versions of Akaros, since
>> > unlikely() isn't in the kernel headers anymore.
>>
>> There is no longer a ros/compile.h? From what I read, I thought that
>> remained, but it just got removed from automatic inclusion in
>> ros/common.h
>
> Nope, it was totally yanked. My rationale was that it's not even part
> of the kernel interface, so we don't need it in there. Given the
> likelihood of collisions (e.g. libunwind), I was hesitant about putting
> it anywhere.
>
> We have a similar issue with ARRAY_SIZE. It used to be part of the
> kernel headers, thinking that common kernel and user code could use it,
> but then it turns out that it's so useful that many projects have it
> too, and then we conflict.
>
> It'd be nice if we could have a way to 'weak alias' these sorts of
> things, but I don't know of any preprocessor tricks to do that.
>
>> I agree. I think we can find a way to make this work completely from
>> userspace, but it will take some magic with getting glibc to compile
>> if we end up calling any parlib/pthread functions from __libc_write().
>
> Yeah, let's sort this out in the flesh!
>
> Barret
>
> --
> You received this message because you are subscribed to the Google Groups
> "Akaros" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
~Kevin
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
