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.
Many thanks for running these benchmarks! Shiro Kawai <shiro@xxxxxxxx> writes: > In the current implementation, a port has a recursive lock and > the pthread_mutex_lock is called when a builtin I/O procedure > is called and the calling thread hasn't acquired the lock. So > the locking doesn't affect the large-granularity operation > such as read or write much, while it is expensive for fine-grained > operation such as read-char/write-char expensive. Gauche > provides a procedure "with-port-locking" to lock the port in > larger granularity, which is what I used to "bypass" the > locking. > > (Maybe I'm doing something stupid; if there's a clever way to > avoid this much of locking overhead, I'd like to be enlightened.) Huh---I'm afraid I don't have a good answer for you other than to use procedures like DISPLAY-STRING. You should be able to do better with input streams through lockless synchronization in the common case---if a buffer is there, it's immutable, after all. For output streams, it's indeed harder. I don't really see thread safety as being local to ports only---the stream framework is just as high-level as the ports, and should be ready for the same tasks. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla