Caroline Maynard wrote:
What do you mean by maintain the status of the thread-safe variant?
document it? continue to make sure that it works when adding new code?
anything else?
I meant the latter - with quite a few different people contributing code
and patches, there's a likelihood that
On 01/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
OK, I was asking because it seems more interesting to support threaded
MPMs on Windows (as a threaded MPM is the default) than on Linux/Unix
where I think the majority of people use forking/multi-process MPMs.
So I was initially
On 01/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Do you think that we should build with the thread safe libs by default?
or have 2 bin libraries one thread safe, one not but faster?
The question applies to both Linux and Windows, and I'm not sure but we
may have different
Caroline Maynard wrote:
On 01/12/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Do you think that we should build with the thread safe libs by default?
or have 2 bin libraries one thread safe, one not but faster?
The question applies to both Linux and Windows, and I'm not sure but
On 21/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
As far as SDO itself is concerned, I think we would be OK if the user of
SDO
could guarantee that whenever an SDO artifact (data factory, data object,
type, XSDHelper ...) is created then that artifact will be used
_exclusively_ by the thread
This is now http://issues.apache.org/jira/browse/TUSCANY-959
Caroline Maynard wrote:
On 21/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
As far as SDO itself is concerned, I think we would be OK if the user of
SDO
could guarantee that whenever an SDO artifact (data factory, data
object,
type, XSDHelper ...) is created then that artifact will be used
On 21/11/06, Caroline Maynard [EMAIL PROTECTED] wrote:
On 20/11/06, Caroline Maynard [EMAIL PROTECTED] wrote:
There's a comment against that posting about exactly this situation,
where
an external library may or may not be thread-safe, and the answer is it
depends. Of course we also depend
On 20/11/06, Caroline Maynard [EMAIL PROTECTED] wrote:
There's a comment against that posting about exactly this situation, where
an external library may or may not be thread-safe, and the answer is it
depends. Of course we also depend on libxml2 as well as your
implementation, but that is a
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
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
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
On 17/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
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
On 17/11/06, Caroline Maynard [EMAIL PROTECTED] wrote:
On 17/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
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
14 matches
Mail list logo
