On Dec 18, 11:06 pm, Joost <jo...@zeekat.nl> wrote: > Erm, what's your master? I'll assume CS.
Well it's software engineering, but close enough :). I should have mentioned that. > Personally, I'm interested in whether complete thread abstraction that > makes "threads" as light-weight as possible, but also the only way to > do concurrency (like Erlang provides with its "processes") is really > the best way to model concurrent programs. I'm over 95% sure that > native threads really are not the best way to model in-process > concurrency for most programs, simply because of all the overhead that > you incur especially when dealing with massively concurrent long- > running thead-like-things - since you both know erlang, you will know > what I'm talking about - that sort of approach really doesn't work in > clojure, that's why clojure uses thread pools for agents etc. > > But maybe a new and lightweight in-kernel thread model is an > interesing subject? Just asking :) Thanks for your suggestion. It's an interesting idea, and we've been considering something along those lines. I don't know if Erlang's processes are even more lightweight than "green threads". According to Wikipedia [1], Linux actually performs really well in terms of context switching OS threads compared to green threads. But I can't find the paper Wikipedia cites, and it seems not to be downloadable from ACM [2]. In any case, we will take this suggestion into consideration. [1] http://en.wikipedia.org/wiki/Green_threads#Performance [2] http://portal.acm.org/citation.cfm?id=603551 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
