Hacker News new | comments | show | ask | jobs | submit login

With Ruby threads you get the worst of both worlds. They are preemptive and user-level.

1.9 will introduce native threads, which aren't much better. Each native thread requires megabytes of memory for its stack. Co-routines require only 64k of memory.

Concurrency in Rubinius should require even less memory overhead as it is stackless.




1.9 will introduce native threads, which aren't much better.

What? They're not only "better", they're actually _threads_, i.e. are able to run in parallel, you know? What are Ruby 1.8 threads good for, except for sitting on sockets?


Producer/consumer where there are multiple I/O bound producers (examples that come to mind: RSS reader, web spider, multiple-file search). They can also be a useful abstraction for things like waiting for events from multiple sources, or running quasi-realtime simulations.

I agree, though, that real threads would be a significant improvement. Or better yet, MxN threads like GHC.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: