Sharing a DataFactory across 2 threads would be "iffy". I think the tool is checking for things like accessing statics rather than sharing instances of objects so it flags up localtime().
Cheers, On 17/11/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
On 17/11/06, Caroline Maynard <[EMAIL PROTECTED]> wrote: > > One of our SDO for PHP users is planning to run in a multi-threaded web > server, and has asked us for a position on thread-safety. > > They have run an evaluation tool and only found one thread-safety issue > - the use of localtime() rather than localtime_r() in in > commonj/sdo/SDODate.cpp. So I intend to raise a JIRA to ask you to > change that - this could be a conditional compile if you don't want to > use the thread-safe libraries by default. > > However I expect you may have some more general thoughts about > potential issues around thread-safety, which I would be interested to > hear ... As far as I know, the development of SDO to date has given zero consideration to running in a multithreaded environment. I am a little surprised that they were only able to identify one thread safety issue. The first one that occurs to me is - what happens if two or more threads are using the same data factory and one thread attempts to modify a data object that the other is deleting? Or - one thread adds a property to a type while the other is creating a data object of that type. Etc. Most likely your customer would dismiss these scenarios with something like "oh, we will never do that", however, in general, SDO is not thread safe, and it will take a good deal of effort to make it so. I'm not aware of any major objection to using the thread safe libraries, however I am a little concerned that doing so may give the impression that SDO is thread safe when it absolutely isn't. Regards, Geoff.
-- Pete
