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