🚀 go-pugleaf

In article <227.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes:
>In <8032@gollum.twg.com> David S. Herron wrote in reply to Ralph Seguin:
>[Difficult to port DNET to SysV UNIX because you need select() to poll a]
>[serial port without hanging until the next character is received.	 ]
>
>On SysV, you might fork a coprocess to read the serial port, then
>communicate with it through a pipe opened with O_NDELAY.  There are
>probably about 5 other more-or-less reasonable ways to do it.	This
>should not be an insurmountable obstacle...
>
>This is arguably not an Amiga topic, but if it will get DNET supported
>under SysV, it will benefit a lot of Amiga users.  I've redirected
>discussion to comp.sys.amiga.tech since this has nothing to do with
>hardware.
>
>Bela Lubkin   * *   //  filbo@gorn.santa-cruz.ca.us   Why do I mention CI$??
>     @      * *    //	belal@sco.com  ...ucbvax!ucscc!{gorn!filbo,sco!belal}
>R Pentomino   *  \X/  Filbo @ Pyrzqxgl +1 408-476-4633, XBBS +1 408-476-4945


    Well, I have no access to SysV so I can't port DNet myself, it is a
    question of finding a good programmer with access to a SysV box and an
    Amiga who wants to do it.

    One thing, O_NDELAY is cute but also a quick way to get lots of people
    angry at you if you use it in a poll loop.	It is actually more useful
    in a non-polled algorithm... you still must have some kind of
    wait-for-event call, and simply means that the program can try to
    anticipate ready data or available write buffer space without having to
    make *two* system calls.  DNet must be able to wait on the following
    events:

	* new connection on listen socket pending
	* read data ready on socket
	* write buffer space available on socket (actually, I think DNet
	  just uses blocking writes for this right now)
	* read data ready on TTY (that the protocol is run over)

    With the current implementation of DNet, using the select() call (which,
    by the way, I hate with a passion but there is no other way to do it
    under BSD), the process itself takes minimal CPU ... 0 if the connection
    is idle in fact, which means that most people can get away with leaving
    themselves connected all day without the sysop noticing.  Even under a
    full load @ 2400 baud the dnet process takes less than 10% of the CPU.

    I do admit to playing to the BSD schedular however, so in a loaded system
    DNet will generally get more CPU than other processes :-).	It also
    recovers nicely from the infamous '20 second swap-out' that happens when
    the machine is totally overloaded with users (read: university running
    BSD 4.2/4.3 on a VAX 750).

    If anybody does intend to take on the job, a word of warning: DO NOT
    USE SIGNALS TO HANDLE IO ON A UNIX MACHINE.  Originally I used the IO
    signal to read data from the tty running the protocol.  This wound up
    using 50% + of the CPU.  Using select() reduced it down to 10% or less.
    For one thing, using select(), if I know I have read a partial packet I
    can 'guess' how long it will take the rest of the packet to come in and
    wait that period of time before making the system call to read the
    data.  Using select() to wait in this manner usually ups the schedular
    priority for your process (since you are waiting on IO and theoretically
    not taking any CPU to do it).  Thus the better performance on a loaded
    machine.

					    -Matt

--


    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA