guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark H Weaver
Subject: Guile's I/O procedures should *not* do thread synchronization
Date: Wed, 26 Mar 2014 01:10:06 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Tue 25 Mar 2014 12:14, "Diogo F. S. Ramos" <address@hidden> 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.

Standard Scheme programs that do their own parsing and printing using
'read-char', 'peek-char' and 'write-char' could be made at least an
order of magnitude faster in the future if we don't make this promise.

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.

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.

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 Guile's own internal read and print procedures, a global find-replace
was done in master to change all of these simple port operations to use
unlocked variants, presumably because it would have caused a major
performance regression otherwise.  What's the plan for portable Scheme
code that implements similar functionality, such as Oleg's libraries?

Most ports (by far) are only accessed by a single thread, but everyone
would have to pay the hefty price of built-in thread synchronization
whether they need it or not.

Finally, robust programs will have to do their own explicit
synchronization anyway.  Multiple threads writing to the same port
without explicit synchronization would lead to garbled output that is
interleaved at unspecified points.  The situation is even worse on the
read side.

In order to do proper I/O on the same port from multiple threads, the
locking _must_ be done within code that understands the meaning of the
data being read or written, because only such code can know where the
data can be interleaved without producing garbage.

For all of these reasons, I would strongly urge us to reconsider the
decision to promise internal locking for Guile's I/O procedures.

   Regards,
     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]