Asynchronous exception bug in spawn about distributed-process HOT 4 OPEN

Asynchronous exceptions are not an issue here because the thread ID of the new thread is not exposed and hence nobody can throw an asynchronous exception to that thread. Nevertheless, you are right of course that we were ignoring the possibility of error in newEndPoint. That's now fixed.

(You are also right that we could potentially removed this completely, but that would require a major version increment. Meh.)

from distributed-process.

Asynchronous exceptions are not an issue here because the thread ID of the new thread is not exposed and hence nobody can throw an asynchronous exception to that thread.

But the RTS can still throw asynchronous exceptions to the new thread.

Nevertheless, you are right of course that we were ignoring the possibility of error in newEndPoint. That's now fixed.

But why execute the newEndPoint inside the new thread and go to the trouble of creating an MVar and waiting for it when you can just execute it in the main thread which is simpler, safer and probably a bit faster to?

from distributed-process.

Yeah, I'm not sure either, but I probably had a (possibly wrong) reason at the time :) You're probably right that it can be simplified, but I couldn't remember why I had done it this way in the first place so I was a bit hesitant to change it.

And if your heap is overflowing inside spawn you have bigger problems :-) Point taken though.

from distributed-process.

It was something to do with not wanting to do certain operations on the main thread, because the main thread is by default a bound thread.. Even so it should probably be okay because newEndPoint will spawn its own threads to do most of the work..

from distributed-process.