Kohn Emil Dan
Mon, 15 Apr 2002 20:21:43 -0700
Hi could also look at the FSU threads package http://www.informatik.hu-berlin.de/~mueller/pthreads/ (This was the user-level POSIX threads I had in my mind while I was arguing on Monday ;-) Emil On Tue, 16 Apr 2002, guy keren wrote: > > i saw this email on the linux-kernel mailing list - its a guy trying to > implement user-level threads on linux, and encountering problems with > making them pre-emptive. this looks similar to what emil was talking about > during last monday's club meeting about Posix threads. > > the reply this guy got, btw, was: > > "Look at how OpenAFS handles this, or use GNU pth." > > so i guess anyone interested in seeing user-level threads implemented in > linux should look for the above two things on google, or just: > > GNU pth (http://www.gnu.org/software/pth/) <-- NON-preemptive threads. > > the LWP implementation in OpenAFS seems to be non-preemptive as well > (OpenAFS is a branch of IBM's AFS - Andrew File System). > > -- > guy > > "For world domination - press 1, > or dial 0, and please hold, for the creator." -- nob o. dy > > ---------- Forwarded message ---------- > Date: Mon, 15 Apr 2002 18:31:46 +0530 > From: Alpha Beta <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: [Haifux] Signal Handler > > i am trying to implement a user level thread package with preemption between threads. > > There is provision for threads relinquishing the processor themselves (ie without >preemption): this is peacefully implemented using setjmp() and longjmp(). > > For preemption, I set a timer using setitimer() and install a signal handler to >catch the signal SIGVTALRM this timer generates. > > When a thead is executing and the timer expires, i enter the signal handler.I want >to save the state the currently interrupted thread had before coming into the signal >handler into a structure similar to jmp_buf(which setjmp() and longjmp() use), so >that signal handler saves this state(to be resumed later when scheduled) and passes >control to another thread. > The important point is that I MUST SAVE THAT STATE OF THIS INTERRUPTED THREAD THAT >IT HAD AT THE TIME OF > GETTING INTERRUPTED BY THE SIGNAL __AND__ __NOT__ THE CURRENT STATE ( the state >inside the > signal handler). > {{ As i think, the reason for this is : > The implementation of signal handlers in linux is done by creating a seperate stack >etc for the signal handler's text > and stack regions, such that at the end of the text region some code is added etc. >to make sure that the signal handler > returns by executing the system call sigreturn (this is required so that the kernel >can do some posix required > book keeping before continuing with the execution of the interrupted process by a >ret_from_sys_call). if i save the context of this interrupted thread in the signal >handler and longjmp() to some other thread's saved state,when i later resume the >execution of this interrupted thread, i'll in effect be resuming execution in this >signal handler and since the signal handler's return address will NOT be valid then : >i won't be returning to the place in the program where i got interrupted earlier, >rather i will return with the sigreturn system call into the kernel, ...... and >everything will turn upside down. > }} > > So the problem boils down to how can i find in the signal handler the state of the >process when the signal was received so that i can put it in a jmp_buf struct and >resume execetion from there. > > > so much for it. > tell me if u can implement preemptive scheduling of C code in a user level threadin >some other way. > > thnx > Abhishek > > > > See Dave Matthews Band live or win a signed guitar > >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info athttp://vger.kernel.org/majordomo-info.html > Please read the FAQ athttp://www.tux.org/lkml/ > > > > -------------------------------------------------------------------------- > Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) > To unsub send an empty message to [EMAIL PROTECTED] > > > -------------------------------------------------------------------------- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]