> > > > There is no particular problem with this behavior > > for > > asynchronously-generated signals. > > > Unfortunately, this creates a problem for me. I'm > implementing a user-level thread library, namely the > M:N model which Sun abandoned. My unit of execution > is (libc) thread which uses signals for preemptive > scheduling and setcontext() family of functions to > switch between my "threads". My "threads" have small > stacks which are allocated on demand, and executing > the signal handler on the regular stack causes stack > overflow and results in data corruption and > eventually in program crash. > > I understand that Solaris 8 had M:N model, and this > is what I'm also implementing. In my case, the unit > of execution is libc thread which schedules my > "threads" by setcontext() family of functions. How > can I go one level "below", namely to directly use > LWPs to schedule my user-level "threads" ? In this > way I'd avoid additional layer (libc threading) and > this signal handling issue. > > Basically, it'd be nice if Solaris provided a way to > construct user-level threading libraries in the M:N > model. :)
Why do you want to do this? IIRC, the M:N model was abandoned because it was seriously hard to get it right, while at the same time, it didn't appear to have any performance advantages, let alone enough to make it worth the extra complexity. I think http://www.sun.com/software/whitepapers/solaris9/multithread.pdf discusses this rather thoroughly. Solaris LWPs (which the current model uses 1:1 to user level threads, AFAIK) are quite efficient compared to some competing OS thread implementations, I think. The only reason I can think of offhand for being able to choose which model to use is to test that the code works ok with either model, and most properly written code should. Indeed, I'd argue that the more serious bugs might only show up with bound threads on a multiprocessor system. (having said the above, I tend to agree that the interfaces should properly function as documented) This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
