From: Peter Olcott on

"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
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

"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
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
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Flushing file writes to disk with 100% reliability
Next: SPAM