"Cons: If a thread crashes, the entire process goes down."
I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false.
"Good luck debugging concurrency bugs."
Good luck debugging concurrency bugs in a callback-driven system!
> I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false.
I'm talking about CPU instruction level crashes, not language level crashes. Things like writing to an invalid memory address or heap corruption.
> Good luck debugging concurrency bugs in a callback-driven system!
Actually I already mentioned concurrency bugs in evented systems in the article.
Comments
"Cons: If a thread crashes, the entire process goes down."
I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false.
"Good luck debugging concurrency bugs."
Good luck debugging concurrency bugs in a callback-driven system!
> I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false.
I'm talking about CPU instruction level crashes, not language level crashes. Things like writing to an invalid memory address or heap corruption.
> Good luck debugging concurrency bugs in a callback-driven system!
Actually I already mentioned concurrency bugs in evented systems in the article.
"Things like writing to an invalid memory address or heap corruption."
So what you're trying to say is if the entire virtual machine crashes, you lose all running threads.