DragonFly kernel List (threaded) for 2003-07
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Call for Developers! Userland threading
:Guess I can give up Usenet for a few months. :)
:
:We should probably agree on a common name for the thread struct that
:isn't likely to overlap anyone else's likely names for thread structs:
:lwkt_thread, lwthread, lw_thread, something like that. maybe grab some
:mindspace: dragonthread?
hahahaha. dragonthread... hahahaha.
lwkt_thread is good for userland. I was going to call the kernel
thread's lwkt_thread but I decided to stick with the 5.x 'thread'
convention.
:> * Use the convenient mostly pre-built message stored in the
:> * userthread structure
:> */
:> msg = &curthread->td_sysmsg;
:
:msg = &curthread->td_sysmsg[READ] or something like that, no?
Not unless you want your user thread structure to become hugely bloated!
td_sysmsg would be a union I think, similar to what I use for DEV
struct syscall_msg {
struct lwkt_msg lmsg;
...
}
struct syscall_read_msg {
struct syscall_msg sysmsg; /* base message structure */
ssize_t result; /* non-error result */
int fd;
void *buf;
size_t bytes;
}
union lwkt_sysmsg {
struct syscall_msg msg; /* base message structure */
struct syscall_read_msg read;
struct syscall_write_msg write;
...
}
Then in the read system call:
struct syscall_read_msg *msg = &curthread->td_sysmsg.read;
(Naming is up for grabs, I'm not set on any particular naming scheme)
A user thread will only be in one direct system call interface
(i.e. read(), write(), gettimeofday()) at a time, so a single
union'd syscall message structure embedded in the lwkt_thread is
sufficient. Other forms of system calls, such as asynch calls or
calls related to the core userland scheduler, would allocate and/or
use their own message structures. There is nothing wrong with,
say, declaring a message structure on the stack, but it does cost
more to have to re-initialize the message every time you want to
send one.
Embedd a single union in lwkt_thread allows us to reuse a message
over and over again without having to reinitialize the core pieces of
it (just like we did on the Amiga with IOReq's).
:> * (later on) development of a kernel-supported signal infrastructure
:> for proper POSIX signal handling.
:
:First pass would be synchronous signal handlers, so caught signals are
:delivered as messages, otherwise they kill or ignore as now?
Right. Ultimately that may be what we choose to use but I think it will
be easier to add a kernel API that allows the threading system to tell
the kernel to just funnel all signals through in a particular way,
regardless of what the user program told the kernel to do in the
signal() (and related) calls. Or something like that. Once the main
pieces of the threading system are working the direction that needs to
be taken in regard to signals will become more obvious.
:> I will be focusing on the kernel side of things. I would like those
:> interested in doing the userland threading project to focus on the
:> userland side of things.
:
:dragonfly.userapi?
I would leave it in .kernel for the moment, because everyone is
interested in everything. When list volume goes up we can break it
and other categories off.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]