Call for Developers! Userland threading

[Matthew Dillon]

: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 at xxxxxxxxxxxxx>