As with subroutines, the type of value returned from a thread's entry point function may be determined by the thread's context: list, scalar or void. The thread's context is determined at thread creation. This is necessary so that the context is available to the entry point function via wantarray(). The thread may then specify a value of the appropriate type to be returned from ->join().
Explicit context
Because thread creation and thread joining may occur in different contexts, it may be desirable to state the context explicitly to the thread's entry point function. This may be done by calling ->create() with a parameter hash as the first argument:
my $thr = threads->create({'context' => 'list'}, \&foo);
...
my @results = $thr->join();
In the above, the threads object is returned to the parent thread in scalar
context, and the thread's entry point function foo will be called in list
context such that the parent thread can receive a list from the ->join()
call. Similarly, if you need the threads object, but your thread will not be
returning a value (i.e., void context), you would do the following:
my $thr = threads->create({'context' => 'void'}, \&foo);
...
$thr->join();
The context type may also be used as the key in the parameter hash followed
by a true value:
threads->create({'scalar' => 1}, \&foo);
...
my ($thr) = threads->list();
my $result = $thr->join();
Implicit context
If not explicitly stated, the thread's context is implied from the context of the ->create() call:
# Create thread in list context
my ($thr) = threads->create(...);
# Create thread in scalar context
my $thr = threads->create(...);
# Create thread in void context
threads->create(...);
Remember: There's always one more bug.
I don't get it. Why are you forced to specify in advance the context that you'll be using? Does threads throw an assertion error if you accidentally use a different context than the one you promised you'd use?
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
No, essentially it is so the the thread 'entry point' (the subroutine that forms the thread essentially) can have a different context than that of the create() which started the thread, that is to say you can tell it in advance what context the join() will be called in so that wantarray() will work properly, bearing in mind that the thread may already have checked wantarray to determine what to return before the context of the join is known.
/J\
Since that's just repeating what I just said, why did you say "No, ..."?
⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊
Er, I don't think I was repeating what you said at all. You asked a question about the necessity to specify the context in advance which I was trying to answer. And you asked "Does threads throw an assertion error if you accidentally use a different context than the one you promised you'd use?" to which I was answering "no".
*shrug*
/J\
Why are you forced to specify in advance the context that you'll be using?As threads execute asynchronously, the context must be set before the thread starts executing because it may call wantarray at any time during its execution, and may even finish before a ->join() call is made on it.
Prior to threads v1.31, the context would be determined by how the ->create() call was made. This lead to the following counter-intuitive syntax if you wanted the threads object, but were expecting to get a list back from the thread:
my ($thr) = threads->create('foo');
...
my @results = $thr->join();
Additionally, this Perl bug
has threads created in void context, but then tries to get return values from
the thread.
With threads 1.31, you can now specify the context directly so as to avoid such confusion:
use threads 1.31;
my $thr = threads->create({'list'=>1}, 'foo');
...
my @results = $thr->join();
threads->create({'context'=>'scalar'}, 'bar');
...
foreach my $thr (threads->list()) {
my $rc = $thr->join();
}
Does threads throw an assertion error if you accidentally use a different context than the one you promised you'd use?No, but you may not get the results you expect.
Remember: There's always one more bug.
Although this adds nothing that cannot already be done, given the disconnect between establishing the return context at thread creation time, and its effect at thread join time, I do see the motivation behind wanting to make that context more explicit.
I do have to wondewr at the need for two separate interfaces though?
thread->create( { context => 'list' }, ...
# -v-
thread->create( { list => 1 }, ...
The latter seems entirely redundant, and also wrong.
- This is a single option with 3 possibilities--not 3 binary options.
- It adds complexity where none is necessary or desirable.
What context results from this?
threads->create( { scalar => 1, void => 1, context => list, list => 0 }, ... - My main objection is the effect on performance.
One of the main use of the return values/context is going to be applications that use the spawn & die mode of operation. Short lived threads that do something, return the results to the parent and exit. Spawn another for the next task. A typical example might be a threaded server.
For this kind of application, the time taken for the spawning thread to start a thread and get back to deal with the next incoming connection is critical to the overall performance. Once a connection has been accepted, the time between the accept and the first read is not critical, but delays in getting back to service the next accept are.
The additional complexity of parsing and validating the dual interface comes at a critical point in those applications that are most likely to make most use of them.
I do have to wonder at the need for two separate interfaces though?The short answer is flexibility. The former is more descriptive; the latter more succinct. Use the style which suits you best.
thread->create( { context => 'list' }, ...
# -v-
thread->create( { list => 1 }, ...
What context results from this?The official answer would be The behavior is unspecified. The technical answer is that the code checks for context first, and would then ignore anything else.
threads->create( { scalar => 1, void => 1, context => list, list => 0 }, ...
My main objection is the effect on performance.At most, the penalty is a few exists calls (1 for context which is first in the code, up to 4 in the case of void which comes last), plus a hash fetch. Further, this feature is implemented in XS code, and so is quite fast.
...
The additional complexity of parsing and validating the dual interface comes at a critical point in those applications that are most likely to make most use of them.
Additionally, if this feature is not used, there is no performance penalty. Therefore, if your code is really that super sensitive to response, don't use it.
Remember: There's always one more bug.