Aaron Sherman wrote:
On Tue, Oct 12, 2010 at 10:22 AM, Damian Conway <dam...@conway.org> wrote:
Perhaps we need to think more Perlishly and reframe the entire question.
Not: "What threading model do we need?", but: "What kinds of non-sequential
programming tasks do we want to make easy...and how would we like to be
able to specify those tasks?"
Things that typically precipitate threading in an application:
- Blocking IO
- Event management (often as a crutch to avoid asynchronous code)
- Legitimately parallelizable, intense computing
Interestingly, the first two tend to be where most of the need comes from
and the last one tends to be what drives most discussion of threading.
Perhaps it would make more sense to discuss Perl 6's event model (glib,
IMHO, is an excellent role model, here --
http://en.wikipedia.org/wiki/Event_loop#GLib_event_loop ) and async IO model
before we deal with how to sort a list on 256 cores...
The last one in particular would legitimately get attention when one considers
that it is for this that the concern about using multi-core machines efficiently
comes into play. The first 2 are more about lowering latency and appearing
responsive to a user on a single core machine. I think that Perl 6's implicit
multi-threading approach such as for hyperops or junctions is a good best first
choice to handle many common needs, the last list item above, without users
having to think about it. Likewise any pure functional code. -- Darren Duncan
