Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default

[Micah Brodsky]

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: address@hidden
[mailto:address@hidden On Behalf
Of Matt Birkholz
Sent: Thursday, April 26, 2012 8:47 PM
To: Taylor R Campbell
Cc: Matt Birkholz; address@hidden
Subject: Re: [MIT-Scheme-devel] multi-threading problem: Unassigned
variable: root-continuation-default

> From: Taylor R Campbell <address@hidden>
> Date: Thu, 26 Apr 2012 22:01:29 +0000
> 
>    Date: Thu, 26 Apr 2012 13:29:33 -0700
>    From: Matt Birkholz <address@hidden>
> 
>    > From: "Micah Brodsky" <address@hidden>
>    > 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
address@hidden
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel