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]
