On Apr 27, 2009, at 10:19 PM, David Berry wrote:
> 2009/4/27 Edward Chapin <[log in to unmask]>:
>> Actually, all of this may be irrelevant. I'm using David's wrapper
>> for
>> pthreads inside smurf (smf_threads.c). When I call smf_add_job, I
>> need to
>> give it a function which has as a prototype a pointer to some
>> thread data,
>> and inherited status. So I suspect he creates a new status instance
>> for each
>> thread function, and handles the status merge himself at the end.
>>
>> Let's see what David has to say...
>
> Yes, my smurf code uses separate status variables for each thread, and
> handles the merging of them into a single workfiorce status. I'm
> hoping this does not conflict with Peter's stuff? Regarding
> emsMark/emsRlse, I assume that the application code calls them at
> suitable places to enclose all multi-threaded operations. This should
> be the case for all adam tasks since the fixed part will do it.
Maybe Ed can experiment in his thread test code.
Create a few threads and randomly decide whether they should fail or
return good status (putting some messages on the stack for good
measure). Then see what comes out on the error message stack at the
end. errAnnul and errFlush should work fine (clearing/dumping the
local thread error message stack).
--
Tim Jenness
Joint Astronomy Centre
|