[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: roo
From: |
Taylor R Campbell |
Subject: |
Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default |
Date: |
Sat, 28 Apr 2012 14:23:51 +0000 |
User-agent: |
IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1 |
Date: Fri, 27 Apr 2012 18:40:16 -0700
From: Matt Birkholz <address@hidden>
... and let's get concrete with the existing thread-event mechanism.
Please don't. It's extremely hard to engineer anything reliably with
it. Any discussion of SIGNAL-THREAD-EVENT that doesn't involve
blocking and unblocking thread events, race conditions, atomicity and
data structure invariants, &c., is a recipe for disaster. We need to
get rid of it except, at most, as a debugging operation and as an
internal mechanism for implementing more principled abstractions.
One example of a more principled abstraction is Scheme-CML, based on
Concurrent ML:
http://mumble.net/~campbell/darcs/scheme-cml/
We also need a better story about interruption, perhaps like Racket's
breaks, but not as the basic mechanism for thread communication.
> [...] Imagine if you couldn't safely do debug prints from a worker thread!
I can only imagine doing it safely if the debug-print procedure grabs
the port/mutex for the duration of the message output (write-line?)
process.
It doesn't help for the debug-printing routine to grab a mutex if
nobody else is cooperating with it. And if you're desperately chasing
down a thread synchronization problem with debug-prints, there's a
good chance someone has forgotten to cooperate.
A write-line made up of tiny atomic write-chars is no more
"safe" except for the precious buffer pointers. I would call them a
costly set of suspenders IF they kept the pants from falling down.
Thread-safe and child-proof are marketing terms.
Interleaving output is one thing. Crashing because of corrupted
internal data structures is quite another.
> 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
Fascinating (as my hero would say, without a trace of sarcasm).
What did you do wrong?
One easy way is to close a channel that someone's waiting to do I/O
on.
- [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, craven, 2012/04/26
- Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Micah Brodsky, 2012/04/26
- Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Matt Birkholz, 2012/04/26
- Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Micah Brodsky, 2012/04/26
- Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Taylor R Campbell, 2012/04/27
- Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Matt Birkholz, 2012/04/27
- Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default,
Taylor R Campbell <=
- Re: [MIT-Scheme-devel] multi-threading fun: closing a socket, Matt Birkholz, 2012/04/30
- Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Taylor R Campbell, 2012/04/27
Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Taylor R Campbell, 2012/04/26
Re: [MIT-Scheme-devel] multi-threading problem: Unassigned variable: root-continuation-default, Taylor R Campbell, 2012/04/26