How reliable are named pipes?
in [Unix Programming]
|
From: Peter Olcott on 10 Apr 2010 13:27 "Moi" <root(a)invalid.address.org> wrote in message news:b7bb6$4bc0a43b$5350c024$19410(a)cache120.multikabel.net... > On Sat, 10 Apr 2010 11:08:06 -0500, Peter Olcott wrote: > >> "Moi" <root(a)invalid.address.org> wrote in message >> news:a56f3$4bc0a145$5350c024$5576(a)cache100.multikabel.net... >>> If you want them buffered, then let the reader buffer. >> >> I guess that's my only choice. > > No, the other choice is to let the writer block. > (which is not as bad as it seems; it makes little sense to > accept work that you cannot handle (yet) ) > It would have provided a simpler design. > And there still is the choice of a spooldir, which offers > you persistence > and atomicity for free. Plus high-capacity ;-) > > AvK I made a note of that.
From: Bob Smith on 10 Apr 2010 14:22 Peter Olcott wrote: > "Bob Smith" <bsmith(a)linux >> Second, the writer can write about 4K bytes before getting >> blocked if the reader is not reading. This is usually not >> a problem but was for some of my robotic control software. >> I now use a proxy device for this. > > That sounds dumb. Why not simply grow the queue length to > some arbitrary pre specified length? Sorry I wasn't clear. The problem is that I don't want any data queued. In my robotic application the data is from a sensor reading. The problem with reading queued data is that the reader has no idea how stale the sensor data is. I wanted something that would block the writer immediately if no reader was present. Bob
From: Peter Olcott on 10 Apr 2010 21:19 "Bob Smith" <bsmith(a)linuxtoys.org> wrote in message news:4BC0C1DD.9080102(a)linuxtoys.org... > Peter Olcott wrote: >> "Bob Smith" <bsmith(a)linux >>> Second, the writer can write about 4K bytes before >>> getting >>> blocked if the reader is not reading. This is usually >>> not >>> a problem but was for some of my robotic control >>> software. >>> I now use a proxy device for this. >> >> That sounds dumb. Why not simply grow the queue length to >> some arbitrary pre specified length? > > Sorry I wasn't clear. The problem is that I don't want > any data queued. In my robotic application the data is > from a sensor reading. The problem with reading queued > data is that the reader has no idea how stale the sensor > data is. I wanted something that would block the writer > immediately if no reader was present. > > Bob In contrast my use is exactly and precisely like waiting lines in a grocery store. It does not matter how long the line gets as long as the jobs are processed in order. The practical limit is about 100 jobs because I also want to limit the customers waiting time one second.
From: Jasen Betts on 11 Apr 2010 04:58 On 2010-04-10, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote: > > My process can handle 100 transactions per second. I was > envisioning a FIFO at least this long. If your process can handle 0.0001 transactions per microsecond. how big do you need the buffer to be? --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Phil Carmody on 11 Apr 2010 05:51
Bob Smith <bsmith(a)linuxtoys.org> writes: > Peter Olcott wrote: >> "Bob Smith" <bsmith(a)linux >>> Second, the writer can write about 4K bytes before getting >>> blocked if the reader is not reading. This is usually not >>> a problem but was for some of my robotic control software. >>> I now use a proxy device for this. >> >> That sounds dumb. Why not simply grow the queue length to some >> arbitrary pre specified length? > > Sorry I wasn't clear. I think you were perfectly clear. > The problem is that I don't want > any data queued. Your 'any' there muddies the water. Apparently you want, or are happy with, a 4k buffer. > In my robotic application the data is > from a sensor reading. The problem with reading queued > data is that the reader has no idea how stale the sensor > data is. I wanted something that would block the writer > immediately if no reader was present. An alternative would be circular-buffer-like - accept new data, but throw away old data rather than processing it (think input devices in linux, which can include some 'measurement' devices like accellerometers and magnetometers, say). That might not be suitable for your particular application, of course. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1 |