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)
|
>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