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 19 Jun 2005 09:41 UTC

>From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
Subject: Re: output streams vs output ports
Date: Sun, 19 Jun 2005 11:09:16 +0200

> Could you clarify what would be expensive about it?  Getting the
> synchronization right is sure difficult to program, but I don't think
> there's a necessarily large performance hit.  (Specifically, Scheme 48
> does it all entirely without locking.)

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?

If I can sacrifice portability a bit, I may use spin lock with
processor-specific synchronization instruction.  (I also need
pthread_cleanup_push/pop to handle cancellation, but I expect
they are lightweight.)

Using pthread mutex and condition variables does hurt.  I'll be
glad if there's a better way.

--shiro