Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: PLEXUS UNIX BOX and Amiga Message-ID: Date: 9 Oct 90 22:44:55 GMT References: <1990Oct3.043213.18022@caen.engin.umich.edu> <8032@gollum.twg.com> <227.filbo@gorn.santa-cruz.ca.us> Lines: 72 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