Re: Stdio.Buffer.set_buffer_mode revisited

Per Hedbor () @ Pike (-) importm?te f?r mailinglistan wrote:
>o I would never ever under any circumastances inherit something more
>  than once. Instead, have an input and an output buffer object.

:-).  Well, it was because it originated from code that used a single
socket to read/write.  I guess I could separate it now.

>  It's a miracle it even works. Note that range_error will be called
>  for both buffer objects,

I know.  Actually, the range_error() is the *only* kind of "conflict"
which arises in this situation.  I tried looking for a way to only override
range_error() in the read buffer version, but so far no luck.

> how do you know which one it is for?

Well, simple actually:
a. I make sure that I never consciously generate a range error on the write
   side.
b. The only write range_error that arises is for howmuch==0, which I catch
   at the beginning and return right away.

>  See also: All your wrappers for the various read_* functions.

Is there anything amiss with those? I thought that was straightforward.

>o Why have transmit()? It is handled automatically when data is added
>  to the output buffer.

In order to reduce network traffic, reduce latency and increase throughput,
I need to decide when to flush the network buffer (I end up with too many
too small packets otherwise).  So the current version
of the automatic output buffer flushing is unsuitable.
I'd love one where I can decide how much can be flushed.

>o There is no need to have a write_cb, really, it should be
>  pointless. Writing is handled by the file object in buffered mode.

That's just it, I cannot use the buffered mode due to too small packaging
on the network side.

>o There seems to be more locking than is strictly needed.
>  Is the cond/locks really needed?

>  The read/write callbacks will always be called from the backend
>  thread (range_error for output buffer and read_cb) so why would they
>  need a condition variable to signal to each other?

Well, in the application code I want to do things like:

   c->read_int8() and c->read_hstring()

and I want the call to block and wait.
Yet, I want the input buffer to filled automatically from the
network using buffer input mode.  The network socket is nonblocking by
itself though.
So, if you know a solution to this which avoid the Condition and the
Mutex(es), I'd love to hear ideas.  But it seems to me that the functionality
I need from Stdio.Buffer for the read side and for the write side
needs a tad bit more native support to make it seamless.
-- 
Stephen.