Re: Unbuffered socket I/O

Hi, Here is an updated patch that adds `setvbuf-input' and `setvbuf-output'. As suggested by Kevin, `setvbuf-{input,output}' now take a MODE argument. Unlike previous versions of the patch, `setvbuf-{input,output}' simply discard the input/output buffer. In addition, `setvbuf' and `fport_buffer

Re: Unbuffered socket I/O

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > Speaking of scm_getc ... I've wondered for a while if some of the low > level reading funcs ought to be looking directly into the read buffer > instead of making a call to scm_getc for every char. My experience > has usually been that a function call

Re: Unbuffered socket I/O

I wrote: > > rdelim `read-line' Oops, I confused myself. It already looks in the buffer - it's the model not the improvable - a few more bits could be like it ... ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/g

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > N calls to `scm_getc ()' Speaking of scm_getc ... I've wondered for a while if some of the low level reading funcs ought to be looking directly into the read buffer instead of making a call to scm_getc for every char. My experience has usually been

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > of `scm_getc ()' translates in one `scm_fill_input ()' call, which in > turn translates in one `select ()' and one `read ()' Coming back to this bit: that select really does seem pretty doubtful. The more I think the more it sounds like a hangover fr

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > +SCM_DEFINE (scm_setvbuf_output, "setvbuf-output", 2, 0, 0, > + (SCM port, SCM size), Can that take a mode, so it's possible to set _IOLBF ? setvbuf-input could also take a mode, though _IOLBF wouldn't be wanted there, but it'd make the args

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > There's `scm_c_read ()' for "read N bytes", but it translates into N > calls to `scm_getc ()'. Then that's where it can best be fixed. > IMO it feels wrong to dismiss the port abstraction There's nothing super fantastic about the ptab funcs, there'

Re: Unbuffered socket I/O

Hi, Attached is an updated patch. Ok to apply? Kevin Ryde <[EMAIL PROTECTED]> writes: >> Besides, how about applying the change I originally proposed to HEAD? > > No, principally because unbuffered is an advertised feature. Hey, it's only advertised as long as we advertise it! ;-) I mean, if

Re: Unbuffered socket I/O

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Ludovic Courtès) writes: >> >>(uniform-vector-read! vec port))) > > Slackness in the implementation of that function. It knows a size to > read and should come out as a read() system call of that size. Yet it > always g

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > >(uniform-vector-read! vec port))) Slackness in the implementation of that function. It knows a size to read and should come out as a read() system call of that size. Yet it always goes through the port buffer. You need to post the probl

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (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 ori

Re: Unbuffered socket I/O

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Ludovic Courtès) writes: >> >> Right. That's an incompatible change if the _output_ is buffered. >> Input can be buffered, though, without this being visible by users. > > Alas, that too is in an incompatible change, because recv! i

Re: Unbuffered socket I/O

Hi, Neil Jerram <[EMAIL PROTECTED]> writes: > I have no technical objection to your patch, but I'm afraid you must > be missing something, or else there is something special about the > environment that you were measuring in. I have played with a few > TCP-based Guile applications (including the

Re: Unbuffered socket I/O

Neil Jerram <[EMAIL PROTECTED]> writes: > > I have played with a few > TCP-based Guile applications (including the Emacs debugging interface) > and not noticed any obvious performance problem. Likewise. I've been reading http headers byte by byte - because I was too lazy to do it properly yet - w

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > Right. That's an incompatible change if the _output_ is buffered. > Input can be buffered, though, without this being visible by users. Alas, that too is in an incompatible change, because recv! ignores buffering. > Fortunately, port buffering does

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > I tried it with TCP server-side sockets and the performance impact is > _huge_. Actually, it seems even hard to write a TCP server without this > because it takes so long to read a single octet that clients may > time-out before the server is done rec

Re: Unbuffered socket I/O

Hi, Kevin Ryde <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Ludovic Courtès) writes: >> #define SCM_SOCK_FD_TO_PORT(fd) \ >> scm_fdes_to_port (fd, "r", sym_socket) > > That's an incompatible change, I think, since it can leave unflushed > data where previously it went straight out. R

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > > Is there a reason why `SCM_SOCK_FD_TO_PORT ()' in `socket.c' asks for an > unbuffered port? To make send and receive conversations reliable, according to sockets section in the manual. (I don't think I added that. I hope I'm not claiming my own wor

Re: Unbuffered socket I/O

[EMAIL PROTECTED] (Ludovic Courtès) writes: > Hi, > > Is there a reason why `SCM_SOCK_FD_TO_PORT ()' in `socket.c' asks for an > unbuffered port? This results in awful inefficiency, as can be seen > with `strace': I don't know the details, but I recall people in the past talking about Guile doin