[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: permissions (and other) problems

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-09-13 18:17:32 CEST

Philip Martin wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>
>
>>Index: subversion/include/svn_error.h
>>===================================================================
>>--- subversion/include/svn_error.h
>>+++ subversion/include/svn_error.h Thu Sep 12 22:49:39 2002
>
> [snip]
>
>>@@ -151,6 +175,8 @@
>> svn_error_t *svn_err__temp = (expr); \
>> if (svn_err__temp) \
>> return svn_err__temp; \
>>+ else if (svn__async_canceled ()) \
>>+ return svn__async_cancelation_error (); \
>
>
> Generating the error by calling a function will mean that the
> debugging line number associated with the error will refer to that
> function. If you called svn_error_create directly would mean that the
> line number would refer to the SVN_ERR macro, which is much more
> interesting, although it may increase the code size.

The reason I moved it into the function was that i needed to get a pool
from somewhere to do the allocation. i suppose i could define a
get_cancelation_pool function, and move the error creation into the ERR
macros... then you could see where exactly you were when you got
canceled, which would be nice.

>> } while (0)
>>
>>
>>Index: subversion/libsvn_subr/cancel.c
>>===================================================================
>>--- subversion/libsvn_subr/cancel.c
>>+++ subversion/libsvn_subr/cancel.c Thu Sep 12 22:36:31 2002
>>@@ -0,0 +1,80 @@
>>+/*
>>+ * cancel.c: support for asyncronous cancelation of subversion functions
>>+ *
>>+ * ====================================================================
>>+ * Copyright (c) 2000-2002 CollabNet. All rights reserved.
>>+ *
>>+ * This software is licensed as described in the file COPYING, which
>>+ * you should have received as part of this distribution. The terms
>>+ * are also available at http://subversion.tigris.org/license-1.html.
>>+ * If newer versions of this license are posted there, you may use a
>>+ * newer version instead, at your option.
>>+ *
>>+ * This software consists of voluntary contributions made by many
>>+ * individuals. For exact contribution history, see the revision
>>+ * history and logs, available at http://subversion.tigris.org/.
>>+ * ====================================================================
>>+ */
>>+
>>+
>>+
>>+#include "svn_error.h"
>>+#include "svn_pools.h"
>>+
>>+
>>+/*** Code. ***/
>>+
>>+static volatile sig_atomic_t canceled = FALSE;
>
>
> Is canceled an Americanism? I'd have spelt it cancelled.

it's more of a "garrett can't spell"ism ;-)

>>+
>>+static svn_boolean_t cancelation_in_progress = FALSE;
>
>
> Why the second flag?

i think it was because i was running into cases where we'd be canceled,
more than once. you'd hit control-c, get the first cancelation, and
then do an SVN_ERR during cleanup and get a second. i might be on crack
though, because it now occurs to me that another bug i fixed in this
code might have been causing that behavior. i'll have to test some more
  when i get back to this.

>>+
>>+static apr_pool_t *cancelation_pool;
>>+
>>+svn_boolean_t
>>+svn__async_canceled(void)
>>+{
>>+ return canceled;
>>+}
>>+
>>+svn_error_t *
>>+svn__async_cancelation_error(void)
>>+{
>>+ canceled = FALSE;
>>+
>>+ cancelation_in_progress = TRUE;
>>+
>>+ return svn_error_create (SVN_ERR_CANCELED, 0, NULL,
>>cancelation_pool, NULL);
>>
>>+}
>>+
>>+svn_boolean_t
>>+svn__async_cancelation_in_progress (void)
>>+{
>>+ return cancelation_in_progress;
>>+}
>>+
>>+void
>>+svn_async_register_cancelation_pool (apr_pool_t *pool)
>>+{
>>+ cancelation_pool = pool;
>>+}
>>+
>>+void
>>+svn_async_cancel(void)
>>+{
>>+ if (! cancelation_in_progress)
>
>
> Given that this is a signal handler, the above test looks a little
> suspicious. Is it necessary? Can't you just set cancelled
> unconditionally? I'm not sure why you need two flags anyway, doesn't
> cancelled provide enough state?

again, i think you might be right. i think the problem that led me to
the two flags may have been something else which i've already fixed.

thanks for the comments. i will take them into account tonight or
tomorrow when i can get back to this.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 13 18:18:08 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.