> From: Taylor R Campbell <campb...@mumble.net> > Date: Thu, 26 Apr 2012 22:01:29 +0000 > > Date: Thu, 26 Apr 2012 13:29:33 -0700 > From: Matt Birkholz <m...@birkholz.chandler.az.us> > > > From: "Micah Brodsky" <micah...@csail.mit.edu> > > Date: Thu, 26 Apr 2012 11:10:47 -0400 > > > While you're at it, do be careful about using sockets from multiple > > threads simultaneously. They're not really thread-safe like native > > OS sockets are. [...] > > Ummm... one should be careful when using ANY resource from multiple > threads... so Scheme's ports/sockets each come with a mutex... so I > can only wonder what you're on about... How "really thread-safe" are > "native OS sockets"? > > The mutex in a port is advisory, not mandatory. MIT Scheme uses it > only to grant ownership of the `console port' to a single thread. > Concurrent use of a port in two different threads can corrupt its > internal state. Concurrent use of a file descriptor (or `native OS > socket', or `channel') from two different threads can't corrupt its in > internal state.
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!) 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. A REPL that grabs its i/o port's mutex once at startup and then reads and writes it freely is an example of that principle in action. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
