Re: Call for Developers! Userland threading

[Craig Dooley <cd5697@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 22 July 2003 04:20 pm, Matthew Dillon wrote:
> :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.

light weight kernel thread _ thread?  what about 
lwkt in kernel
lwut in userspace or just lwt?

>
> :> 	       * 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?

The upcall system of KSE seems like the best way to preempt a process for 
signals.  Even though there should only be one message port from what I 
understand, what about 2, and having one do an upcall for things which need 
immediate attention?  If im misunderstanding and every time a message is 
receive it jumps to a handler just ignore me.

>
>     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>

- -Craig
cd5697@xxxxxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/HcjiYXswu1EOVs0RAlntAKCk21lOi66B+45JqVwMWo9bhA3AHACfXYSR
zJqrG69TQnZI+duKYGp0/gI=
=Go5i
-----END PGP SIGNATURE-----