[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: output streams vs output ports
From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: output streams vs output ports
Date: Mon, 20 Jun 2005 07:41:21 +0200
> > Is there a portable way (i.e. can be written in portable C)
> > to avoid calling synchronization primitives (e.g. pthread_mutex_lock)
> > if the implementation uses native threads?
> But if you're using native threads, aren't read(2) and write(2)
> already thread-safe in some sense? (I really don't know.)
If the port I/O is just a thin, stateless layer on top of OS
syscalls, yes. But I imagine it's hardly the case---if the
port buffers the data, you need mutex in the port layer, for
example. So do srfi-6 string ports.
> That's where most of the potentially expensive synchronization is,
> anyway. There's a little bit in the streams layer, but I'm not sure
> avoiding that would be worth the potential pain.
The simple-minded copy program:
(do ((c (read-char in) (read-char in)))
(write-char c out))))))
It runs 3.5x faster if I bypass locking of 'in' and 'out' ports
in Gauche. The port buffers I/O data, so OS call is far less
frequent than the port access, almost negligible.
The output buffered stream of srfi-68 reference implementation
doesn't seem MT-safe. I thought the locking will be handled
in the port layer, but do you think the stream should take care