Hi! So, threads and ports again. We didn't really come to a resolution in this thread:
http://article.gmane.org/gmane.lisp.guile.devel/17023 To recap, in Guile 2.0 a port has mutable internal state that can be corrupted when when multiple threads write to it at once. I ran into this when doing some multithreaded server experiments, and fixed it in the same way that libc fixes the issue for stdio streams: https://www.gnu.org/software/libc/manual/html_node/Streams-and-Threads.html#Streams-and-Threads Namely, ports can have associated recursive mutexes. They can be in a mode in which every operation on a port grabs the mutex. The interface to set a port into unlocked mode (à la fsetlocking) is unimplemented, but the machinery is there. This change fixed the crashes I was seeing, but it slows down port operations. For an intel chip from a couple years ago the slowdown was something on the order of 3x, for a tight putchar() loop; for Loongson it could be as bad as 26x. Mark was unhappy with this. Mark also made the argument that locking on port operations doesn't always make sense. Indeed I quote from the libc documentation: But there are situations where this is not enough and there are also situations where this is not wanted. The implicit locking is not enough if the program requires more than one stream function call to happen atomically. One example would be if an output line a program wants to generate is created by several function calls. The functions by themselves would ensure only atomicity of their own operation, but not atomicity over all the function calls. For this it is necessary to perform the stream locking in the application code. So we don't yet expose the equivalent of flockfile, but at this point since there are still concerns out there I wanted to ask if the current solution still makes sense. I hope this is a fair summary of the issue. My perspective on this is that crashes are unacceptable, and also that it does make sense to log to stderr from multiple threads at once. When writing to ports under error conditions you don't always have the luxury of being able to coordinate access in some nicer way. I sympathize with the desire to make put-char etc faster, as that means that more code can be written in Scheme. One possible alternate solution would be to expose ports more to Scheme and so to make it easier and safer for Scheme to manipulate port data. This would also make it possible to implement coroutines in Scheme that yield when IO would block. Or, we could just make stdio/stderr be locked by default, and some other things not. Seems squirrely to me though. Dunno. I would add that although there is a solution to this issue in master, it might not make it into 2.2. There will probably be a dozen prereleases before 2.2.0, so even if a 2.1.1 manages to make it out the door before we come to a solution, that doesn't mean that the choices in such a release are the right or final ones. Regards, Andy -- http://wingolog.org/
