On 13 February 2015 at 18:54, Philip Martin wrote:
> Philip Martin writes:
>
>> Ivan Zhakov writes:
>>
>>> This API is present from Subversion 1.2, so I suggest add call to
>>> svn_dso_initialize2() in svn_ra_initialize()/svn_fs_inialize(): do you
>>> have any objections against this approach?
>
Philip Martin writes:
> Ivan Zhakov writes:
>
>> This API is present from Subversion 1.2, so I suggest add call to
>> svn_dso_initialize2() in svn_ra_initialize()/svn_fs_inialize(): do you
>> have any objections against this approach?
>
> Yes, that sounds like a good idea.
No objections. And,
Ivan Zhakov writes:
> This API is present from Subversion 1.2, so I suggest add call to
> svn_dso_initialize2() in svn_ra_initialize()/svn_fs_inialize(): do you
> have any objections against this approach?
Yes, that sounds like a good idea.
--
Philip Martin | Subversion Committer
WANdisco // *
On 12 February 2015 at 21:28, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> As far I understand out testsuite still may fail in some rare
>> circumstances with --parallel option, until we add
>> svn_dso_initialize2(). It's bad when tests are failing sometimes.
>
> I just seen a failure and it r
Ivan Zhakov writes:
> As far I understand out testsuite still may fail in some rare
> circumstances with --parallel option, until we add
> svn_dso_initialize2(). It's bad when tests are failing sometimes.
I just seen a failure and it revealed the current bug. I think the
tests explicitly clear
On 12 February 2015 at 20:51, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> Sorry, but I've lost what problem we're trying to solve now? Why just
>> do not add call to svn_dso_initialize2() (or svn_cmdline_init()) in
>> our testsuite and move forward?
>
> What do we gain? We already have progr
Ivan Zhakov writes:
> Sorry, but I've lost what problem we're trying to solve now? Why just
> do not add call to svn_dso_initialize2() (or svn_cmdline_init()) in
> our testsuite and move forward?
What do we gain? We already have programs that that call
svn_dso_initialize2: svn, svnserve, ... I
On 12 February 2015 at 20:27, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> Please understand my correctly: I'll be glad see Subversion doesn't
>> require single-thread initialize functions, but I don't see how is it
>> possible in reliable way. Currently the only reliable solution is to
>> cal
> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: donderdag 12 februari 2015 16:59
> To: Subversion Development
> Cc: Philip Martin
> Subject: Re: svn commit: r1659013 -
> /subversion/trunk/subversion/libsvn_subr/dso.c
>
> On 11 Febr
Ivan Zhakov writes:
> Please understand my correctly: I'll be glad see Subversion doesn't
> require single-thread initialize functions, but I don't see how is it
> possible in reliable way. Currently the only reliable solution is to
> call svn_dso_initialize2() as first call after apr_initialize(
Ivan Zhakov writes:
> Why you didn't make svn_atomic__init_once() internal implementation
> details of svn_dso_initialize2()?
That would be better, so r1659315.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
On 12.02.2015 16:58, Ivan Zhakov wrote:
> On 11 February 2015 at 20:48, wrote:
>> Author: philip
>> Date: Wed Feb 11 17:48:06 2015
>> New Revision: 1659013
>>
>> URL: http://svn.apache.org/r1659013
>> Log:
>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>> fixes a crash in the D
On 11 February 2015 at 20:48, wrote:
> Author: philip
> Date: Wed Feb 11 17:48:06 2015
> New Revision: 1659013
>
> URL: http://svn.apache.org/r1659013
> Log:
> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
> fixes a crash in the DSO hash code when running the C tests in
> paralle
On 12 February 2015 at 16:48, Branko Čibej wrote:
> On 12.02.2015 14:17, Philip Martin wrote:
>> Ivan Zhakov writes:
>>
>>> Multi-threaded application that didn't call svn_dso_initialize2()
>>> before creating any other pools will fail anyway under some
>>> circumstances. The problem with cleanup
On 12.02.2015 14:17, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> Multi-threaded application that didn't call svn_dso_initialize2()
>> before creating any other pools will fail anyway under some
>> circumstances. The problem with cleanup handles, not with concurrent
>> initialization.
> Perhaps
Ivan Zhakov writes:
> Multi-threaded application that didn't call svn_dso_initialize2()
> before creating any other pools will fail anyway under some
> circumstances. The problem with cleanup handles, not with concurrent
> initialization.
Perhaps we could fix the problem (for recent APR) by usin
Branko Čibej writes:
> On 12.02.2015 13:26, Evgeny Kotkov wrote:
>> Philip Martin writes:
>>
>>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>>> fixes a crash in the DSO hash code when running the C tests in
>>> parallel.
>>>
>>> * subversion/libsvn_subr/dso.c
>>> (atomic_in
On 12 February 2015 at 15:42, Branko Čibej wrote:
> On 12.02.2015 13:26, Evgeny Kotkov wrote:
>> Philip Martin writes:
>>
>>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>>> fixes a crash in the DSO hash code when running the C tests in
>>> parallel.
>>>
>>> * subversion/libsvn
On 12.02.2015 13:26, Evgeny Kotkov wrote:
> Philip Martin writes:
>
>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>> fixes a crash in the DSO hash code when running the C tests in
>> parallel.
>>
>> * subversion/libsvn_subr/dso.c
>> (atomic_init_func): New.
>> (svn_dso_load
Philip Martin writes:
> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
> fixes a crash in the DSO hash code when running the C tests in
> parallel.
>
> * subversion/libsvn_subr/dso.c
> (atomic_init_func): New.
> (svn_dso_load): Use svn_atomic__init_once.
I think we should als
20 matches
Mail list logo
