Re: Unbuffered socket I/O

[Kevin Ryde <user42@zip.com.au>]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> Below is a tentative patch (I chose more meaningful names since they
> don't relate to `setvbuf(3)').

Call them setvbuf.  Two names for the same thing is more confusing
than one (slightly obscure) name.

> Besides, how about applying the change I originally proposed to HEAD?

No, principally because unbuffered is an advertised feature.  Even if
it was year zero you'd probably still choose them to start unbuffered,
since there's various ways to do comms and it can be up to an
application how much might be desirable.  For block operations for
instance it's certainly not wanted.

> That would require changing `recv!', `send', etc. so that they are
> somehow "buffering-aware".

That could be ok.  I doubt it makes much sense, because buffering is
more or less stream oriented yet those funcs are about packets.  But
they could still look at the buffers in the interests of keeping data
in sequence.

> Afflicted by what?

Blocking in one thread prevents gc in any other thread, bringing
everything to a screeching halt, before long.


> +	    "Use a @var{size}-octet

Say "byte" not "octet".  Octet sounds like one of those dreadful CCITT
standards.

> +  size_t c_size;
> +  c_size = scm_to_uint (size);

There's an scm_to_size_t for that.

+      if (c_offset > c_size)
+	scm_wrong_type_arg_msg (FUNC_NAME, 1, port,
+				"Input buffer must be flushed before it "
+				"can be shrunk");

The current code silently discards, I think that's probably enough.
If it was up to me I might move it to the putback buffer though.

> +      if (c_size == 0)
> +	new_buf = &pt->shortbuf, c_size = 1;

I suppose an explicit request for size==1 could use the shortbuf too,
though I see the existing code doesn't do that.  (Maybe there's a
reason it doesn't.)

I expect there's a memory leak there if you don't free the old buf
when becoming unbuffered.

> +      if ((pt->read_buf_size == 0) && (pt->write_buf_size == 0))
> +	SCM_SET_CELL_WORD_0 (port, SCM_CELL_WORD_0 (port) | SCM_BUF0);

That'd need to turn the flag off too, if it's become non-zero.

> +      if (c_offset > c_size)
> +	scm_wrong_type_arg_msg (FUNC_NAME, 1, port,
> +				"Output buffer must be flushed before it "
> +				"can be shrunk");

That doesn't need to be an error does it?  Can't it be flushed there
and then?

Otherwise looks ok as long as it actually works! :)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel