joe@oilean.uucp (Joe McGuckin) (11/26/90)
I have an application that needs to send/receive stuff from a serial port in an async. manner. I know that Unix's tip forks a seperate processes for sending and receiving chars. This seems kludgey to me - plus, I want the main process to be able to communicate with the sending and receiving code. Can someone suggest a better way than forking?? What about sigvec() - it looks as if one could create user level interrupt routines that get triggered when characters are available for I/O on a file/device... -joe joe@parcplace.com -- Joe McGuckin oilean!joe@sgi.com Island Software joe@parcplace.com (415) 969-5453
debra@svin02.info.win.tue.nl (Paul de Bra) (12/10/90)
In article <1990Nov26.092137.5629@oilean.uucp> joe@oilean.uucp (Joe McGuckin) writes: >I have an application that needs to send/receive stuff from a serial port in >an async. manner. I know that Unix's tip forks a seperate processes for sending >and receiving chars... Look at the source for kermit (public domain). As far as i know it does everything with only one process. Paul. debra@research.att.com, debra@win.tue.nl
jfh@rpp386.cactus.org (John F Haugh II) (12/11/90)
In article <1629@svin02.info.win.tue.nl> debra@svin02.info.win.tue.nl (Paul de Bra) writes: >In article <1990Nov26.092137.5629@oilean.uucp> joe@oilean.uucp (Joe McGuckin) writes: >>I have an application that needs to send/receive stuff from a serial port in >>an async. manner. I know that Unix's tip forks a seperate processes for sending >>and receiving chars... > >Look at the source for kermit (public domain). >As far as i know it does everything with only one process. Ah, but Kermit cheats. It sends packets and then receives packets - it is very much a synchonous protocol. For async transfers you need something more clever. The "real" answer is the use select(), poll() or some combination of vmin=0/vtime=0 termio magic. Issue a select() call for all of your fd's and let the system figure it out ... -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
dnichols@uunet.uu.net (DoN Nichols) (12/12/90)
"Paul de Bra says:" > > In article <1990Nov26.092137.5629@oilean.uucp> joe@oilean.uucp (Joe McGuckin) writes: > >I have an application that needs to send/receive stuff from a serial port in > >an async. manner. I know that Unix's tip forks a seperate processes for sending > >and receiving chars... > > Look at the source for kermit (public domain). > As far as i know it does everything with only one process. As far as I know, kermit does fork an extra process for copying characters back to the terminal while conversing with the other end. When kermit is doing a transfer, it needs to know the answers, and, I believe, kills the other process. This is based on what I remember of VERY old source code for kermit (It was about three or four source files then), and on seeing two kermits when doing a ps while kermit was running on another terminal. At kermit's present size, I just look at enough code to get it working on whatever system I'm using at the moment. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
ske@pkmab.se (Kristoffer Eriksson) (12/13/90)
In article <18801@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >Ah, but Kermit cheats. It sends packets and then receives packets - it is >very much a synchonous protocol. > >The "real" answer is the use select(), poll() or some combination of >vmin=0/vtime=0 termio magic. But C-kermit does just that. Especially nowadays whit sliding windows and all that. In protocol mode, that is. In terminal mode, it uses two separate processes. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske