|From:||David Leimbach <leimy2k@xxxxxxx>|
|Date:||Fri, 21 Nov 2003 18:42:29 -0600|
On Thu, Nov 20, 2003 at 07:50:57PM -0500, Michal Ostrowski wrote:On Thu, 2003-11-20 at 19:31, Matthew Dillon wrote:...I am not trying to create a procedural abstraction, but I do intend to use
messaging to initiate syscalls so in a sense that is a procedural
abstraction of a kind since it causes things like read() to be moved into
libc and actually build, dispatch, and wait for the syscall message
rather then make a directly 'read' system call.Underneath all of this, I think there are interesting issues arising from interactions between thread management and IPC.
Like what ? priority messaging issues ? just curious.
With regard to the second issue you've touched upon, we implement UNIX
API's as you've described. Our approach to this has been to move as
much functionality into the application as possible. Thus things such
as file-cursor management can be handled within the application under
certain circumstances, and poll()/select() are implemented completely
within the application. Such an approach allows us to potentially
supply specialized implementations of services on a resource by resource
Is this a Linux emulator ? Something that might be kind of interesting
is the possiblity of borrowing code from each project for implementing
a Linux emulator. How complete are your Posix threading semantics ? just
curious again about corner cases. :) Those things have been a classic
killer in Solaris and other M:N threading systems.