Date: Thu, 26 Apr 2012 17:47:01 -0700 From: Matt Birkholz <m...@birkholz.chandler.az.us>
You seem to think "native OS sockets" are channels, but Micah is talking about a Scheme port -- more comparable to a libc "stream", no? Do the latest libcs ensure putc and getchar are thread-safe? (I hope not: what a waste!) By `native OS sockets', I understood Micah to mean what you get out of the socket(2) system call, i.e. file descriptors, whose closest representatives in MIT Scheme are channels. libc streams are indeed analogous to Scheme ports, although the libc stream operations you quoted do lock the stream so that two concurrent uses of putc, getc, &c., won't hose your stream. What's the point? In practice you need to ensure that the large-ops like readline or run-list-command are atomic (per port). Tiny amounts of write/read-octet consistency are no help at all. Sequence the large-ops and the micro-ops will behave themselves. Although we don't do it, there is a point to making the `micro-ops' lock the port: then the port's internal data structures won't get corrupted. Different threads might get weird views of the input, or cause interleaved output, but the port itself won't be corrupted so that a subsequent operation on it will crash. (There is also an associated performance loss which is enormous, and which motivated putc_unlocked, getc_unlocked, &c., in libc.) _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
