Understanding the FreeBSD locking mechanism

[Chris Torek]

>I considered some variation of this scheme when I worked on the
>non-executable stack support. AFAIR the reason why I decided not to do
>this was that the kernel-injected signal trampoline is still needed
>for backward ABI-compat. In other words, the shared page would be
>still needed, and we would end up with both libc trampoline and kernel
>trampoline, which felt somewhat excessive.

Those are pretty much the same reasons I never did it as well.

>Selecting one scheme or another based e.g. on the binary osrel was too
>fragile, e.g. new binary might have loaded old library, and the kernel
>trampoline still must be present in this situation.

The method by which to select the scheme, though, is straightforward:
old vs new signal system call numbers and/or flags.  ("Flags" presents
issues if users of existing mechanism are not good about clearing
unknown flag bits.)

Besides non-executable stack / shared-page, this would also be
particularly good for cases where a runtime library (not
necessarily libc itself, perhaps for other languages) wants a
different signal handling method in user space.  For instance,
instead of signals being delivered to some existing thread as
interrupts, they might spin off new threads entirely.

I think it's still worth pursuing, but it's one of those "forever in
the future, low priority" ideas.  I can't even seem to get back to
my medium-priority ideas these days...

Chris