libvchan, why read random number of characters

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

libvchan, why read random number of characters

Jarvis Roach
Does anyone know of the reason why in libvchan/node.c the writer() function reads in a random (bounded by BUFSIZE) number of bytes from STDIN? Similar question for why a random a number of bytes (bounded first by BUFSIZE and then by the actual number of bytes avail) are read in from the ring buffer before writing them to STDOUT. I didn't see anything in the commit history and couldn't find any comments in the source code explaining why or if this is needed.

-JbR

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: libvchan, why read random number of characters

Roger Pau Monné-3
On Fri, Aug 11, 2017 at 07:36:27PM -0400, Jarvis Roach wrote:
> Does anyone know of the reason why in libvchan/node.c the writer() function
> reads in a random (bounded by BUFSIZE) number of bytes from STDIN? Similar
> question for why a random a number of bytes (bounded first by BUFSIZE and
> then by the actual number of bytes avail) are read in from the ring buffer
> before writing them to STDOUT. I didn't see anything in the commit history
> and couldn't find any comments in the source code explaining why or if this
> is needed.

It's much more faster to read/write in batches rather than writing a
single character at a time. But I'm not sure if that answer your
question because I'm not sure I fully understand the question.

Maybe you can send a patch showing how you think it should be done
instead?

Thanks, Roger.

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: libvchan, why read random number of characters

Roger Pau Monné-3
Please don't drop xen-users.

On Tue, Aug 29, 2017 at 01:40:21PM -0400, Jarvis Roach wrote:

> On Tue, Aug 29, 2017 at 5:49 AM, Roger Pau Monné <[hidden email]>
> wrote:
> >
> > On Fri, Aug 11, 2017 at 07:36:27PM -0400, Jarvis Roach wrote:
> > > Does anyone know of the reason why in libvchan/node.c the writer()
> function
> > > reads in a random (bounded by BUFSIZE) number of bytes from STDIN?
> Similar
> > > question for why a random a number of bytes (bounded first by BUFSIZE
> and
> > > then by the actual number of bytes avail) are read in from the ring
> buffer
> > > before writing them to STDOUT. I didn't see anything in the commit
> history
> > > and couldn't find any comments in the source code explaining why or if
> this
> > > is needed.
> >
> > It's much more faster to read/write in batches rather than writing a
> > single character at a time. But I'm not sure if that answer your
> > question because I'm not sure I fully understand the question.
> >
> > Maybe you can send a patch showing how you think it should be done
> > instead?
> >
> > Thanks, Roger.
>
>
> Agreed, but it looks like the current implementation would, on the rare
> occasion, split up thebatch needlessly because the randomly selected size
> limit would be less than the actual amount of data to be processed.
>
> Here's a quick diff of what I think it could/should look like (for 1 of 2
> locations):
>
> @@ -104,8 +104,7 @@
>  {
>   int size;
>   for (;;) {
> - size = rand() % (BUFSIZE - 1) + 1;
> - size = read(0, buf, size);
> + size = read(0, buf, BUFSIZE);
>   if (size < 0) {
>   perror("read stdin");
>   libxenvchan_close(ctrl);
>
>
> https://github.com/mirage/xen/blob/master/tools/libvchan/node.c
>
>
> I think it's leftover from some kind of desire to test the ring buffer
> behavior with different size parameters.


Right, could you please send that as a formal patch to xen-devel [0]?

Thanks, Roger.

[0] https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users