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

RE: svn commit: rev 834 - trunk/subversion/libsvn_wc

From: Sander Striker <striker_at_apache.org>
Date: 2002-01-11 17:30:54 CET

> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: 11 January 2002 17:20
> Subject: Re: svn commit: rev 834 - trunk/subversion/libsvn_wc
>
>
> On Fri, Jan 11, 2002 at 03:00:45PM +0000, Philip Martin wrote:
> > The problem with APR_DELONCLOSE is that (on Unix at least) the file
> > gets unliked just after creation and so cannot be passed to an
> > external diff program. Pool cleanup handlers can be used (and diff
> > does use them) but these need to be removed before invoking the
> > external diff program because the child process will run it's version
> > of the handlers. It's painful...
>
> There are two types of cleanups passed to apr_pool_cleanup_register:
>
> plain_cleanups - called only when the pool is destroyed
> child_cleanup - called when a child is created
>
> As I understand your issue, simply removing the child_cleanup
> function (i.e. set it to NULL) should be sufficient.
>
> Sander can bash me to pieces if I'm wrong. -- justin

*BASH* *BASH* :)

No, Justin is almost right. We had a nice new way of setting
cleanups to a noop by passing NULL. However, since we decided
to fully stick to the old API for cleanups (at least for now),
you have to pass in apr_pool_cleanup_null.

So, it's just plain:
apr_pool_cleanup_register(pool, your_data, your_cleanup, apr_pool_cleanup_null);
 
Ofcourse this will only work when you have control over adding/removing
the cleanup. If the cleanup is added in an apr function, you can't
do anything about it (other than telling us it is broken ;).

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:56 2006

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.