Re: Add `scm_std_read ()'

[Ludovic Courtès]

Hi,

Neil Jerram <address@hidden> writes:

> I'm not sure.  There are two cases which previously didn't leave and
> re-enter guile mode, and now do: (i) where there is already input
> available (fport_input_waiting), (ii) where the fd is non-blocking.

Right, good point.

> Leaving and re-entering guile mode feels quite expensive to me; it's
> at least locking and unlocking a mutex.  I'm surprised that doesn't
> outweigh the gain of not calling select() a couple of times.  Are you
> sure that it does?

Looking more closely at the output of the `read.bm' benchmark, we see
this (excerpt):

  - Without `scm_std_read'

    ("read.bm: read: _IONBF" 5 total 6.69 user 1.84 system 4.84
    ("read.bm: read: _IOFBF 4096" 100 total 3.13 user 3.05 system 0.08

  - With `scm_std_read'

    ("read.bm: read: _IONBF" 5 total 4.41 user 2.22 system 2.21
    ("read.bm: read: _IOFBF 4096" 100 total 3.11 user 3.07 system 0.05

This shows that less time is spent in the kernel, especially in the
unbuffered case (as is the case with sockets), leading to a noticeable
improvement in the unbuffered case.  OTOH, part of the system overhead
is shifted to user-level in the buffered case, leading to little or no
improvement.

Conclusion: even if it's nice to improve the unbuffered case given the
current state of affairs with sockets, it probably needs some more
thought to benefit the more general case as well.

Thanks,
Ludovic.