[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 doesn't have to be symmetrical (although the > API allowing to do that is internal---actually, we might want to expose > and document `scm_fport_buffer_add ()'). Sounds good. Perhaps `setvbuf-input' and `setvbuf-output' for the two directions. They could go in 1.8 too if you're careful with the implementation. Might have to check the SCM_BUFLINE and SCM_BUF0 flags are ok though. Suspect the answer is yes, SCM_BUFLINE being an output side feature, and SCM_BUF0 already merely a combination read==unbuf + write==unbuf. > Thus, I propose the following > change, where sockets are turned into ports whose output is left > unbuffered and whose input is buffered. The manual could emphasise that unbuffered is not what you want if reading piecemeal, but the default should stay as advertised. > BTW, do you know what the purpose of `fport_wait_for_input ()' is? Maybe left from the 1.6 cooperative threads. > It > does nothing for O_NONBLOCK streams and waits for events otherwise. > Since, for blocking streams, `read ()' does not return until either EOF > is reached or at least one octet was read, `fport_wait_for_input ()' > seems redundant. Ahh, hang on, I wonder if it's a hack to do an "exit guile" while blocked within a read(), thus allowing gc to run in other threads. If that's true then presumably the write side is afflicted too, as well as various other potentially blocking operations like read-string!/partial and gethost. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
