threads->reallyNew( \&code, ... );.

This would start a new interpreter, do no cloning beyond those internal things necessary to make the interpreter work, and would simply run the coderef I provide. No closures. No cloned uses. Do nothing except what I choose to do explicitly.

I like that idea. I do however enjoy the syntax of using closures to pass data to new threads, so some intermediate api may also be desirable.

Example:

  my $iq = $control->input_queue;
  my $oq = $control->output_queue;
  threads->new(sub {
    ...
    // use $iq/$oq in here.
    ...
  });
[download]

A threads::shared::share() that does what it says on the tin--ie. shares what I ask it to share. The current design
* that will take a named aggregate object, but not an anonymous one (by-passable).
* And silently empties that object before sharing the base reference.

is so broken as to be ridiculous. How anyone ever thought that silently discarding user data was a good idea beggars belief.

Amen, re disgarding initial value... is that not just bad use of tie() ? (or maybe I misunderstand the mechanism)

In general, I find very few examples (in the kind of applications I deal with) where fast access to tons of shared data is really necessary, so at least for me, Storable doesn't really pose too many speed/correctness issues.

I have to admit I feel dirty every time I touch a lock... where possible I like to design data-structures and APIs such that I don't have to reason too deeply about locks when I go to maintain them. Of course that imposes certain problems with speed/granularity/composability.... and is the reason I posted Where is concurrency going? Is Perl going there?

The best example of this interface is Thread::Queue. With it's provision of ->dequeue(), ->dequeue_nb() and ->pending() methods, it addresses each of the scenarios above, giving its owners complete control, without ever requiring them to think about locking.

Agreed... it really boils down to how easy it is to reason about imperative code. Robust message-passing simplifies design, and reduces the concurrency problem to: "How do I avoid a deadlock?"

I think I'd be nice to have more advanced concurrency primitives available... but at this stage that's a pipe-dream... it's a really good idea to get the shared-memory stuff into good shape and into the core.

If it's not too much of a problem, I'd also like to be able to switch the method by which data is shared as a pragma (eg: pthread, shmem, mmap, etc)...

-David