> My reason for disliking this patch is that it adds user-space information
> to the kernel - in a place where user space cannot get at it.
>
> In particular, any traditional cooperative user-space threading package
> wants to switch its own stack around, and they all do it by just changing
> %esp directly. The whole point of such threading is that it's _fast_,
> since it doesn't need any kernel support (and since it's cooperative, you
> can avoid locking).
>
> The old "optimization" that you didn't like was not an optimization at
> all: it got the case of user space changing stacks _right_, while still
> allowing yet another stack for signal handling and exiting the signal by
> hand.
>
> Does anybody do that? I don't know. But it was done the way it was done on
> purpose.
Yes, GNU Pth :
http://www.gnu.org/software/pth/
and, for example :
http://www.xmailserver.org/libpcl.html
They use the generic POSIX stack setup described here :
http://www.gnu.org/software/pth/rse-pmt.ps
My Pine's 'd' key deleted his patch before I could take an exhaustive
look, but it should be fine though. They both do use to enter the signal
handler simply to get a snapshot of the context, and they exit the handler
by letting the kernel to clean the on-sig-stack flag. try to search
archives to take a better look at the patch ...
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/