I was talking about kernel-level abstractions like sockets. In most systems, you can close them or change their options from another thread concurrently with conducting IO on them, which can be very handy for cancellation and termination. Now, such kernel-level atomicity properties are entirely irrelevant to MIT Scheme, except inasmuch as the same problems reappear and are much more of a pain to deal with without them. I.e., as far as I can tell, everyone who wants to abort a blocking call like a socket read has to roll their own abstraction to handle safe cross-thread signaling.
I am not aware of anyone trying to automatically sync application-level IO ops across threads in native C (and probably futile for C++ chained stream ops, as much as I might love it for convenience...). But they certainly need to worry about the integrity of their buffer pointers! Imagine if you couldn't safely do debug prints from a worker thread! I have not looked at the spec or code in the case of glibc, but I know for certain MS's stdio and iostream protect their buffers with locks. MIT Scheme has some particularly bad failure modes when you rub its sockets the wrong way from multiple threads, i.e. producing an infinite explosion of interrupt-triggered errors that surfaces on socket close, well after the offending code has run, and almost un-debuggable because all you can interact through is the interrupt menu. The only way I figured that one out is by asking Taylor to tell me what I did wrong. :P In a perfect world, it would be lovely if these issues were cleaned up in some way... Alas, I'm neither sufficiently competent nor free to tackle them myself. (Though I'd be happy to share what workarounds I've hacked together for signaling and a aborting with anyone who needs.) --Micah -----Original Message----- From: mit-scheme-devel-bounces+micahbro=csail.mit....@gnu.org [mailto:mit-scheme-devel-bounces+micahbro=csail.mit....@gnu.org] On Behalf Of Matt Birkholz Sent: Thursday, April 26, 2012 8:47 PM To: Taylor R Campbell Cc: Matt Birkholz; mit-scheme-devel@gnu.org Subject: Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default > 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 _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
