> Gee... if this text is only worth 2 cents, why are books so expensive ?
hehe > Anyway, let's give it a try: > > > If the above app installed a signal handler, it is called. The > application > > can stay in the signal handler as long as it wants as far as I am aware, > > but I am not sure if there is a way to get out of the signal handler > > without execution resuming at the offending write access (??). From > > what I read in the signal() manpage, although BSD will block this signal > > from re-occurring, other OSes will install SIG_DFL as the handler, > > and so if any more of these signals are generated the application will > > be put to sleep. > > > > If the above app SIG_IGN's the signal, I don't know what happens. > > It would be best if in this case we could just block the access(es) and > > resume them when the app regains the focus. > > If the program does nothing, the kernel stops the thread. If the program > does something, the whole idea relies on the assumption that whatever it > does, it is a good thing. The idea relies on the assumption that there is > an userspace lib that knows what it is doing, but in fact the entire > accelleration unit of KGI relies on that. > > > I'm not sure how easy this would be to use in the threaded case because > > I don't know how the corner cases of threads work. The default > behavior, > > I believe, will be to put all threads in the application to sleep. > > > > A threaded application with its own signal handler would catch the > > signal, but I am not sure if this pauses all threads or just the > > one causing the signal (?). If threads were still running they could > > violate again and that would cause a SIG_DFL action to occur, making > > the whole process fall asleep. (Please folks correct me if I'm wrong > here.) > > Have no idea, but note that there are also different thread > implementations. THere are implementations that schedule within one task > (pthread ?) and that generate multiple tasks. (The old way linux did it) > NetBSD has found an amazingly efficient way to handle threads: http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html Latest information about NetBSD's new thread implementation (taken from http://www.netbsd.org/Changes/#merge-nathanw_sa): ------------------------------------------------------------------- nathanw_sa branch merged with -current (17 Jan) Jason Thorpe has merged the nathanw_sa branch with -current. NetBSD now has a high performance, modern kernel thread implementation using Scheduler Activations in the main source tree. This work was performed by Nathan Williams with contributions by several other developers. While NetBSD has supported symmetric multiprocessing (SMP) on a number of systems for some time now, native kernel-assisted threads are another big step forward: SMP provides system-level parallelism; multiple independent processes can run concurrently on different CPUs. Multi-threading provides application-level parallelism; multiple threads within the same process can run concurrently on different CPUs; concurrency requires kernel support for threads, which is what Scheduler Activations provides. Many applications today use a threaded software architecture (rather than the traditional Unix model of multiple cooperating independent processes), and so having an efficient threads implementation is an important goal of the NetBSD project. Scheduler Activations is an efficient method of mapping N userland threads to M kernel threads which avoids both the concurrency problems of N:1 implementations and the scalability problems of 1:1 implementations. With native threads now available in NetBSD-current, applications from pkgsrc will readily pick it up upon rebuild, and things will be fixed over the coming time. For instructions on how to port existing applications and to use threads in your own programs using the new libpthreads that comes with NetBSD now, see http://www.humanfactor.com/pthreads/. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr f�r 1 ct/ Min. surfen!
