Re: Guile's I/O procedures should *not* do thread synchronization

[Andy Wingo <wingo@pobox.com>]

On Wed 26 Mar 2014 06:10, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
n>
>> On Tue 25 Mar 2014 12:14, "Diogo F. S. Ramos" <dfsr@riseup.net> writes:
>>
>>> It's not obvious that ports are not thread-safe and trying to have
>>> multiple threads writing to one returns errors that are not
>>> recognizable as been caused by this lack of thread-safeness.
>>
>> This is a bug, and it is fixed in master.  FWIW.
>
> FWIW, I disagree that this is a bug.  I continue to believe that it
> would be a very serious mistake to promise to do thread synchronization
> within Guile's standard I/O procedures.

It seems to work for glibc streams.  Why do you think that thread
synchronization is inappropriate for Guile if it works for glibc?  If
you need more speed you can disable thread synchronization.  (Admittedly
there is no API for that yet, but the possibility exists, as in libc.)

> This could be done in a future version of Guile by uniformly using a
> fixed encoding (UTF-8 or maybe UTF-32) for the port buffers of textual
> ports, and doing the coding conversion when the buffer is filled or
> flushed.

We can do this already.

> However, if we promise to do thread synchronization, we will condemn
> Guile to forever having dog slow 'read-char', 'peek-char', 'write-char',
> 'get-u8', 'peek-u8', and 'put-u8' operations.

I think you are wrong about "dog slow".  Uncontended mutexes are fast,
and we can disable mutexen entirely for certain ports.

> Consider string ports, for example.  They could be the basis for a very
> natural and efficient method of writing string operations, especially
> when we move to UTF-8 encoding of strings internally and string indexing
> becomes less efficient, but only if we have fast single-character I/O.

In the case of SRFI-13-style procedures with fresh string output ports,
we can avoid synchronization.  For input ports, synchronization is
really cheap as you don't ever have to rebuffer.

In summary, I think this is a non-issue.

Regards,

Andy
-- 
http://wingolog.org/