Neil Hodgson wrote:
Exposing a pointer to the current job outside locking is somewhat
dangerous. It looks like it is currently safe but it would be easy for
changes to the code to break thread safety. I just checked in some
changes that improve thread safety in the current code because of
small additions made over time without thought about possible thread
issues. For CurrentJob(), I'd avoid the possibility of breakage where
easy. For example, there could be a safe accessor to getting the
current job directory that used locking and made a copy of the
directory string for SciTEBase::Execute.
I do not fully agree with you Neil. SciTEWin invokes
SciTEBase::Execute() only where there is a job ready to run. I would
think that if a second thread was going to start a job, the first one
running would block it
I've moved the "executing = true;" assignment to the top of the method,
though, and I've implemented jobQueue.CurrentJobDirectory()
.... Moving any use of job to
before the point where IDM_JOBS joins in makes it safer.
I've repositioned the code, introducing a long int variable to preserve
the job exit state.
Since this is complex processing, the section could reasonably be moved into a
separate method.
I'll re-examine this later. The above revisions seem to work.
Thank you Neil.
April
--
Laugh and the world laughs with you. Cry and you cry with your girlfriends.
-- Laurie Kuslansky
_______________________________________________
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
