Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!haven.umd.edu!uflorida!atlantis.cis.ufl.edu!leh From: leh@atlantis.cis.ufl.edu (Les Hill) Newsgroups: comp.unix.programmer Subject: Re: using signal to (portably) wake up a select call Keywords: select, signal, portability Message-ID: <28427@uflorida.cis.ufl.EDU> Date: 7 May 91 21:16:55 GMT References: <2748@optima.cs.arizona.edu> Sender: news@uflorida.cis.ufl.EDU Reply-To: leh@atlantis.cis.ufl.edu (Les Hill) Organization: U of Florida. Computer Science Dept. Lines: 28 In article <2748@optima.cs.arizona.edu>, bakken@cs.arizona.edu (Dave Bakken) writes: |> Is there a way to portably use signal (or something else) to |> wake up a select call? ...stuff deleted... |> In our application we just need to wake up the select call, but can't |> afford to lose an IPC "poke," so if there is not sure way to avoid |> this with signals (which seems to be the case, so far as I can ascertain) |> then we will have to find something else. ...stuff deleted... |> Dave Bakken Internet: bakken@cs.arizona.edu Are you sure you understnad the rudimentary aspects of select()? You are not going to lose an IPC poke by not having select() "running". From the man page (SunOS 4.1.1): select() examines the I/O descriptor sets whose addresses are passed in readfds, writefds, and exceptfds to see if some of their descriptors are ready for reading, ready for writing, or have an exceptional condition pending. Unless you are reading and/or writing elsewhere, your FDs (if ready before the call to select()) will cause the select() call to return immeadiately (the so called "poke" :) Perhaps what you want is asynchronous I/O (which is a different story.) -- Extraordinary crimes against the people and the state have to be avenged by agents extraordinary. Two such people are John Steed -- top professional, and his partner, Emma Peel -- talented amateur; otherwise known as "The Avengers." INTERNET: leh@ufl.edu UUCP: ...!gatech!uflorida!leh BITNET: vishnu@UFPINE