[Haifux] Re-Run votes reminder
So far I've received 5 votes. Onelecture recieved 3 votes Three lectures recieved 2 votes each Twelve lectures recieved 1 vote each Vote today! -- Orr Dunkelman, [EMAIL PROTECTED] If God is perfect, why did he create discontinuous functions? -- .//yro footnote Spammers: http://vipe.technion.ac.il/~orrd/spam.html -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
[Haifux] user-level threads: Signal Handler (fwd)
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 thread in 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 at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Haifa Linux Club Mailing List (http://linuxclub.il.eu.org) To unsub send an empty message to [EMAIL PROTECTED]
Re: [Haifux] user-level threads: Signal Handler (fwd)
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]