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

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.