Explicit thread context

Version 1.31 of the threads module has been uploaded to CPAN. This version adds the capability to specify the context to be used for the ->join() call.

THREAD CONTEXT

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();
[download]

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();
[download]

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();
[download]

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(...);
[download]

Remember: There's always one more bug.

Comment on Explicit thread context Select or Download Code

Replies are listed 'Best First'.
Re: Explicit thread context by BrowserUk (Patriarch) on May 23, 2006 at 16:25 UTC
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 wonder at the need for two separate interfaces though? `thread->create( { context => 'list' }, ... # -v- thread->create( { list => 1 }, ...` [download] 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 +}, ...` [download] 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. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]
Re^2: Explicit thread context by jdhedden (Deacon) on May 23, 2006 at 17:24 UTC
I do have to wonder at the need for two separate interfaces though? thread->create( { context => 'list' }, ... # -v- thread->create( { list => 1 }, ... The short answer is flexibility. The former is more descriptive; the latter more succinct. Use the style which suits you best. What context results from this? threads->create( { scalar => 1, void => 1, context => list, list => 0 }, ... 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. My main objection is the effect on performance. ... 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. 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 entirely in XS code, and so is quite fast. 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.	[reply] [d/l] [select]
Re: Explicit thread context by diotalevi (Canon) on May 23, 2006 at 15:40 UTC
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? ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^2: Explicit thread context by jdhedden (Deacon) on May 23, 2006 at 16:46 UTC
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();` [download] 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(); }` [download] 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.	[reply] [d/l] [select]
Re^2: Explicit thread context by gellyfish (Monsignor) on May 23, 2006 at 15:50 UTC
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\	[reply] [d/l] [select]
A reply falls below the community's threshold of quality. You may see it by logging in.