DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Call for Developers! Userland threading
Craig Dooley wrote:
The upcall system of KSE seems like the best way to preempt a process for
signals. Even though there should only be one message port from what I
understand, what about 2, and having one do an upcall for things which need
immediate attention? If im misunderstanding and every time a message is
receive it jumps to a handler just ignore me.
The question isn't whether there's one port or two, but what you
do about the signal once it reaches user space.
1. Preempt the current thread and start it running the
signal handler.
2. Preemptively switch to the thread that registered the
handler and start running the signal handler.
3. Cooperatively run the signal handler in the next
available thread.
4. Cooperatively run the signal handler in the thread that
registered it.
5. Preempt the current thread and run the signal handler
in a special signals thread.
6. Cooperatively run the signal handler in the signals
thread.
There are advantages and disadvantages to all of these.
The cleanest way to do it would be for the signal() call request
that signals be delivered to the process's reply port as messages
for the thread that registered the signal handler, and Wait()
would deal with these messages by running them in that thread
when it calls Wait() after completing a signal handler (remember,
userland threads are cooperative, so when Wait() gets that message
that thread *is* in Wait() already, so it only needs to check if
it's handling a signal.
The downside is that if you're looping and not calling Wait() the
signal handler can be indefinitely deferred. There are a number of
ways to handle this, but they all involve a moderate amount of
bookwork so it's probably best to set that aside until later.
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]