Re: libthr and 1:1 threading.

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Wed, 2 Apr 2003 16:26:26 -0800 (PST)
    That's a cute trick.  The ultimate solution is to implement 
    a semi-synchronous message passing API to replace the myrid
    system calls we have now.  Roughly speaking, what the Amiga
    did for messages, ports, and I/O, is far superior then what
    is done in Linux and *BSD.  You get the benefit of being able
    to operate syncnronously when possible, and having a convenient
    cup-holder for the operation state if you decide you have to
    'block' the operation (instead of the state being strewn 
    all over the call stack in a syscall implementation).  Userland
    can decide whether to block or not block on an operation
    entirely independant of the OS deciding whether to block or not
    block on an operation.

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>


:Without wanting to get too far off into the weeds, squid does something
:interesting.  They need to be able to nonblock for everything including
:open(), read(), unlink(), readdir() etc.  So what they do is implement a
:fairly significant superset of the traditional AIO stuff using pthreads. It
:seems to work pretty well for them, even with linuxthreads style threads.
:Granted, squid's needs are not exactly typical.  But I did want to point
:out that a good part of the delays come not only from data IO but operations
:like opening a file (pathname traversal), creating or removing a file,
:reading a directory etc.  This is a particular problem when the disk
:is really busy.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com
:"All of this is for nothing if we don't go to the stars" - JMS/B5
Received on Wed Apr 02 2003 - 14:26:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:02 UTC