Re: just curious

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Well, for "a normal API" read "a traditional UNIX API". I don't see any 
:reason the Dragonfly API couldn't be used directly by applications.
:
:> However, there 
:> isn't really any support on clients for say stat file x - if it has 
:> changed read bytes i - j and then write z to byte k.
:
:Ah, this is the same problem, basically, as out-of-order scheduling at 
:the processor "microcode" level. If there's a dependency in the 
:scheduling you get a bubble in the pipeline: in this case the read and 
:write are dependant on the stat, so they can execute in parallel but 
:they can't start until the stat completes... *or* you can schedule the 
:read anyway and throw the data away if the stat fails... and the optimum 
:strategy is different depending on the relative cost of the operations 
:and how close to the critical path they are.

    This sounds suspiciously like transaction support.   One could 
    theoretically bundle several syscall messages together and ask the kernel
    to act on them atomically.

    One could also very easily bundle several syscall messages together
    for the purposes of reducing syscall overhead.  i.e. one transition into
    the kernel, run N system calls in order, one transition back to userland.

    Another thing that shouldn't be missed here is that a messaging syscall
    interface allows us to use an incremental development model for the
    userland and kernelland threading support.  The userland can fire off
    'asynchronous' system calls to the kernel without being any the wiser
    as to how the kernel actually deals with them.  We could initially 
    implement an internal rfork() mechanism for the kernel to run the
    'asynchronous' system calls.

    Userland thread library development could proceed without having to
    wait for complete threading support in the kernel, and asynchronization
    of individual blockable syscalls in the kernel can be worked on 
    in piecemeal and in parallel.

    That's a very big deal!  It makes me want to tackle the syscall
    messaging next, but I'm set on doing DEV first.  Maybe I'll tackle
    the basic syscall messaging support before I do VFS.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>