API noodling

[Matthew Dillon]

:
:>     hahahaha.  dragonthread... hahahaha.
:
:I assumed there was a dragon:thread Pern pun in 'dragonfly'.

    No, but it's a great association.  Actually more then one pun.  Think
    about it.. Dragon... Fly!  That's like three puns in one!

:> 
:>     Not unless you want your user thread structure to become hugely bloated!
:
:I was thinking of caching them, not bothering to init the message structure
:for a given message type until it was used the first time.
:
:	if (!curthread->td_sysmsg[READ]) {
:		curthread->td_sysmsg[READ] = malloc(...);
:		... initialise the type and size fields for READ ...
:	}
:
:Also, don't you need to tell it *which* system call it's using somewhere? :)

    Oh, I didn't include that.  Sorry.  Obviously...

    msg->cmd = SYSCALL_CMD_READ;

    The core message initialization is the same for all messages, so a 
    single message structure stowed away in the thread is sufficient.  All
    you need to setup after that is the command and arguments, and then
    off it goes!

:Using a union won't give you prebuilt templates for the versionless
:universal compatibility sceme you were talking about.

    The union is really just a space allocation.  We can add some padding,
    and anyway the emulation layer *will* be aware of the user program's
    release since it's syscall entry points (e.g. 'read()') have to be
    compatible.

:>     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.
:
:Two... one for when it's in a signal... if signals aren't handled in a
:separate thread.

    The td_sysmsg idea was just for messages we might send, to optimize
    standard system calls.  Incoming messages would be handled differently.
    We don't have to use the pre-cache approach for all of our message types,
    just for the ones in the critical path to streamline the interface.
    Signals aren't really in the critical path so those could be allocated.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>