3 ms·
I would advise the author to read up on "asynchronous exceptions" and check out how many systems have had them at some point and removed them. I'm not saying t
by jerf 3y ago
I would advise the author to read up on "asynchronous exceptions" and check out how many systems have had them at some point and removed them.
I'm not saying that's because they're fundamentally impossible, but because they have a track record of tripping up language designers and it's good to cross check against the experiences.
Recommended languages are Java (ultimately a failure despite vast effort), and Haskell and Erlang where they work, but a lot of work of very different kinds was put in to make it work. I definitely get Erlang vibes from this piece so it's possible the preconditions for correct asynchronous exceptions are met or can be met here. But they are very subtle and have a tempestuous history of working 99.9% but it being literally impossible to get to 100%. This could be a big, big, big trap.
- theamk 3y agohuh? Do not see anything asynchronous in author's work. It's all synchronous, because IPCs in hubris are synchronous too.
- steveklabnik 3y agoI am not familiar with what you're talking about (but Cliff may already know), I'll have to look into it. But Hubris is a synchronous system, and also, these faults aren't catchable, so I'm not sure how directly relevant it is. What's the specific issue you're worried about? Your Erlang vibes are there for good reason, it's certainly an influence.
- jerf 3y agoReaching out and nuking other... whatever you call them, "execution contexts" is what I go for to be maximally generic (thread/async task/continuation/generator/etc.), can particularly cause problems if the context was going to do X, Y, and Z and expected to be able to be guaranteed to run Z, but Y killed it. The standard example is for X to be taking a lock and Z to release it, but there are a lot of ways to get into trouble and the obvious first solutions don't work. Erlang solves it by locking what things it has that can have that problem behind other execution contexts that don't get killed when the main one dies, so they can still clean up. ("Ports", in their terminology.) Haskell solves it by being a functional language and beating the collective community's head in it for several years. (Immutability helped a lot, laziness took out back.) If that sounds impossible... hey, great! Then I just pattern matched on something that wasn't a match. If that doesn't sound impossible, then it may be worth a look around. Synchronousness may not really matter, I've kind of thought that "asynchronous exception" is not a good name for the issue for a while, but it's what it gets called. It's really about one execution context lobbing errors/exceptions into others. Although being synchronous would avoid the worst timing issues.
- steveklabnik 3y agoAh, that problem in general I am familiar with, yes. Tasks in Hubris are independently compiled programs, not threads in a shared context. So I don't believe that it's an issue. You don't share locks between tasks, you create a task that holds the shared resource, and have the two tasks that want to share it talk to that task, patterns like that.
- beeeeerp 3y ago>Recommended languages are Java (ultimately a failure despite vast effort) Why is Java a failure? Recent JVMs have come a long way, and GraalVM makes it somewhat comparable to Go-like languages. I understand the historical hate and how Oracle bought it, but it really isn’t that bad of a language if you’re using modern Java.
- steveklabnik 3y agoThey're referring to that specific feature of Java being a failure, not the language in general.
- j16sdiz 3y agoThe parent was talking about async exception in java -- like the InterruptedException . They are hard to work or reason with.