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

Re: output streams vs output ports

This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.



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