An update:
I added a special case for thread id 0, though this is not ideal. For
better or for worse, my module does not provide any thread entry points. It
simply provides an unconventional means for sharing data across threads.
This means that a user of this module could launch an async{} block that
pulls in the shared data and modifies it. It also means that they can never
share data that originated in an async block.
I've thoroughly documented all of this and I don't think this will be too
much of a problem for most users. However, if I could get some way, even an
XS-based way, to know if a thread is still alive, that would be quite handy.
Thanks!
David
On Tue, Dec 4, 2012 at 10:02 PM, Mike Pomraning
<m...@pilcrow.madison.wi.us>wrote:
> On Tue, Dec 4, 2012 at 9:15 PM, David Mertens <dcmertens.p...@gmail.com>wrote:
>
>> Thanks for the explanation. Can you think of any way (apart from hackery)
>> that I could check that a detached thread with the given tid exists? I do
>> not need to manipulate it, I just need to know if it exists. I might
>> consider tracking the existing threads through a shared array, but then I
>> would have to modify the content of that shared array in an END block,
>> which seems to be discouraged <<SNIP>>
>>
>
> You could wrap every user-supplied entry point function in your own
> enclosing, anonymous sub for bookkeeping. This sub is the true entry point
> passed to threads->create(), and it touches `our %Tids : shared` before and
> after invoking the user-supplied sub. Thread 0 is still a special case.
>
> Liz's Thread::Exit has an example of this approach.
>
> -Mike
>
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan
