Hi,
As Jeff mentions, [ns_info threads] can dump a list for you. You can also play
with [ns_thread name newName] to set the name of the thread as a means to
indicate what it's doing, e.g.,
ns_thread name "worker:waiting"
and then:
ns_thread name "worker:running"
However, the thread name and listing feature is more for debugging or
monitoring purposes with a single coarse-grained lock around a single list so
it may have trouble on a very busy server if threads are coming and going
quickly (admit-ably this is a low probability problem).
One criticism of pthreads is the lack of a non-blocking join which could have
allowed you to create non-detached threads and check if they've exited with a
wait like you could with ordinary Unix processes. Solaris threads had a "wait
for any thread" which wouldn't be too useful either unless you were 100%
certain you were the creator of all detached threads. It looks like there is a
non-standard extensions in Linux, i.e., pthread_tryjoin_np, and you could
fiddle around with creating a Tcl command for this modeled on [ns_thread join]
with non-detached threads.
But all that sounds hard. And, perhaps you're on Windows? So, maybe your own
data structure is better. Just be careful to watch for race conditions with
proper mutex locks and/or relying on atomic-features of nsv, something like
this (caution: I just typed the below, not guaranteed to be correct or useful):
#
# Use a myWorkers nsv to store start and stop time of detached worker threads.
#
proc starterThinger {} {
set nextId [nsv_incr myWorkers nextId]
nsv_set myWorkers start,$nextId [ns_info time]
nsv_lappend myWorkers active $nextId
set tid [ns_thread begindetached [list workerProc $nextId]]
}
proc workerProc {myId} {
... do something useful ...
nsv_set myWorkers done,$myId [ns_info time]
... ok to die ...
}
proc checkerThinger {} {
set active {}
foreach id [nsv_get myWorkers active] {
if {[nsv_exists myWorkers done,$id]} {
nsv_unset myWorkers done,$id
nsv_unset myWorkers start,$id
... do something with knowledge thread died, perhaps
the start and stop time are useful too ...
} else {
lappend active $id
}
}
nsv_set myWorkers active $active
}
The use of worker-pool specific id's instead of thread id's is a paranoia that
thread id's could be re-used, perhaps quickly, fuddling things up. However,
the checkerThinger proc has a race condition of scanning the active list and
then reseting it -- the startThinger could have started a thread during the
check. So, that at least is a known bug.
Anyway, all the above is likely overkill ... consider using [ns_info threads]
first instead :)
Cheers
-Jim
On Jun 27, 2012, at 6:53 PM, Jeff Rogers wrote:
> You can get a list of running threads with [ns_info threads], one of the
> items returned there is the threadid which should correspond to a value
> returned from [ns_thread id]
>
> Alternately, you could have your detached threads set some richer state
> info than running/not running in a nsv and use that to create a status
> display.
>
> -J
>
> Sep Ng wrote:
>> I have a few tasks that I launch with ns_thread begindetached and I'm
>> wondering if I am able to use threadids to monitor them with AOLserver.
>> Any ideas on how I can tell if the thread id is still active or if it
>> exited already?
>>
>> Thanks!
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>>
>> _______________________________________________
>> aolserver-talk mailing list
>> aolserver-talk@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/aolserver-talk
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> aolserver-talk mailing list
> aolserver-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/aolserver-talk
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
aolserver-talk mailing list
aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk
