Email list hosting service & mailing list manager

output streams vs output ports Taylor Campbell (18 Jun 2005 00:26 UTC)
Re: output streams vs output ports Michael Sperber (18 Jun 2005 07:57 UTC)
Re: output streams vs output ports Taylor Campbell (18 Jun 2005 15:17 UTC)
Re: output streams vs output ports Michael Sperber (18 Jun 2005 18:51 UTC)
Re: output streams vs output ports Shiro Kawai (18 Jun 2005 21:06 UTC)
Re: output streams vs output ports Michael Sperber (19 Jun 2005 09:09 UTC)
Re: output streams vs output ports Shiro Kawai (19 Jun 2005 09:41 UTC)
Re: output streams vs output ports Michael Sperber (20 Jun 2005 05:41 UTC)
Re: output streams vs output ports Shiro Kawai (20 Jun 2005 09:16 UTC)
Re: output streams vs output ports Michael Sperber (21 Jun 2005 07:43 UTC)
Re: output streams vs output ports Shiro Kawai (21 Jun 2005 08:08 UTC)
Re: output streams vs output ports Michael Sperber (27 Jun 2005 05:45 UTC)

Re: output streams vs output ports Shiro Kawai 20 Jun 2005 09:16 UTC

>From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
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