Re: output streams vs output ports

[Shiro Kawai <shiro@xxxxxxxx>]

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:

   (call-with-input-file "/usr/share/dict/words"
     (lambda (in)
       (call-with-output-file "/dev/null"
         (lambda (out)
           (do ((c (read-char in) (read-char in)))
               ((eof-object? c))
             (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
of it?

--shiro