![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
This I have discovered recently
Jul. 14th, 2012 08:24 pmSo, I've been fiddling around with Perl, and threading.
One of the things that's been bugging me, is that when I've tried to do a 'return' from a perl subroutine, it's not worked - and I couldn't for the life of me figure out why.
What's _supposed_ to happen, is that you do 'thread -> join' to join the thread (once it's finished running) and that's supposed to capture the return result.
Why it wasn't working is thanks to this little snippet in the documentation (Yes, RTFM, I know. But to be fair, I wasn't looking for it in _that_ bit).
"The context (void, scalar or list) for the return value(s) for "->join()" is determined at the time of thread creation."
Perhaps I'd better backtrack a little though - I mean, anyone who's not really 'into' perl, might not have a clue what I'm talking about when I say 'context'.
So I shall summarise.
Perl is quite clever - it has two 'real' variable types - scalar - which contains anything that's a single value (So any string, integer, float, character, reference). And array (or list) - which is a group of zero or more scalars.
The clever bit is that it can figure out what you mean, by the context in which you do it - a brief illustration (lj cut to avoid breaking formatting).
( code here )
What's happening is the rather clever function 'wantarray' is being used to tell the call context of the subroutine 'wantarray' is undefined if it's a void context (the result is discarded). True if a list/scalar context and false if in a scalar context.
As for why this is useful - consider if you do something like 'grep' - a Unix command to find 'matches' against text patterns. If you do it in a 'list' context, having a list of the lines it found would be useful. If you do it in a scalar context, then having a number of matches is probably more useful (0 being 'false' you could do 'if grep("pattern", @text_block)' for example)
So anyway - the context of a threaded subroutine is set when the thread is _created_.
Which means you need to do something like:
( Read more... )
On the face of it, you immediately discard '$thread' because it drifts out of scope (and it does). However, it also means your thread is created in a scalar context, so any results it returns will be scalar.
If you _don't_ do this, it'll be in a void context, and any return is discarded. Which was what was tripping me up.
And you will then be able to do:
( Read more... )
Which won't work if you don't start the thread in a scalar context.
One of the things that's been bugging me, is that when I've tried to do a 'return' from a perl subroutine, it's not worked - and I couldn't for the life of me figure out why.
What's _supposed_ to happen, is that you do 'thread -> join' to join the thread (once it's finished running) and that's supposed to capture the return result.
Why it wasn't working is thanks to this little snippet in the documentation (Yes, RTFM, I know. But to be fair, I wasn't looking for it in _that_ bit).
"The context (void, scalar or list) for the return value(s) for "->join()" is determined at the time of thread creation."
Perhaps I'd better backtrack a little though - I mean, anyone who's not really 'into' perl, might not have a clue what I'm talking about when I say 'context'.
So I shall summarise.
Perl is quite clever - it has two 'real' variable types - scalar - which contains anything that's a single value (So any string, integer, float, character, reference). And array (or list) - which is a group of zero or more scalars.
The clever bit is that it can figure out what you mean, by the context in which you do it - a brief illustration (lj cut to avoid breaking formatting).
( code here )
What's happening is the rather clever function 'wantarray' is being used to tell the call context of the subroutine 'wantarray' is undefined if it's a void context (the result is discarded). True if a list/scalar context and false if in a scalar context.
As for why this is useful - consider if you do something like 'grep' - a Unix command to find 'matches' against text patterns. If you do it in a 'list' context, having a list of the lines it found would be useful. If you do it in a scalar context, then having a number of matches is probably more useful (0 being 'false' you could do 'if grep("pattern", @text_block)' for example)
So anyway - the context of a threaded subroutine is set when the thread is _created_.
Which means you need to do something like:
( Read more... )
On the face of it, you immediately discard '$thread' because it drifts out of scope (and it does). However, it also means your thread is created in a scalar context, so any results it returns will be scalar.
If you _don't_ do this, it'll be in a void context, and any return is discarded. Which was what was tripping me up.
And you will then be able to do:
( Read more... )
Which won't work if you don't start the thread in a scalar context.
