I hope to have something ready to release before the end of the year, maybe a
sleepycat license. I got a rudimentary shell thread working, so I began
thinking that it would be nice if the shell didn't have any built-in commands,
but could just call functions in the "os" or the "application," and
D. writes:
> >Why are you doing this? Don't the existing threads provide a much
> more robust and better-performing solution? It sounds like you're
> recreating the old Solaris 8 two-level thread library, which we
> intentionally removed seven years ago because it's an inferior
> solution (PSARC 20
>Why are you doing this? Don't the existing threads provide a much
more robust and better-performing solution? It sounds like you're
recreating the old Solaris 8 two-level thread library, which we
intentionally removed seven years ago because it's an inferior
solution (PSARC 2001/287).
I am not tr
D. writes:
> So I wrote a user threads lib. The threads run in a Solaris process. Signals
> occur on the stack of whatever thread is currently executing. I get signals,
> like SIGINT, etc., and can let them unwind naturally. But I thought that I'd
> like to unwind the exception from within the e
So I wrote a user threads lib. The threads run in a Solaris process. Signals
occur on the stack of whatever thread is currently executing. I get signals,
like SIGINT, etc., and can let them unwind naturally. But I thought that I'd
like to unwind the exception from within the exception handler, i
