apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: PATCH: apr_reslist_invalidate
Date Sun, 14 Mar 2004 23:46:29 GMT
Nick Kew wrote:
> Rationale: if an module gets a resource that proves to be bad (e.g.
> a connection that's gone away), it shouldn't be returned to the
> pool to be given out again.  We should invalidate it.
> 
> I'm proposing the following patch, though I'm not sure whether
> or not we should free_container in the event of destroy_resource
> returning an error(?)
> 
> 
> --- apr-util/include/apr_reslist.h.old  2004-01-02 02:46:38.000000000 +0000
> +++ apr-util/include/apr_reslist.h.new  2004-01-02 02:50:43.000000000 +0000
> @@ -150,6 +150,15 @@
>  APU_DECLARE(apr_status_t) apr_reslist_release(apr_reslist_t *reslist,
>                                                void *resource);
> 
> +/**
> + * Invalidate a resource in the pool - e.g. a database connection
> + * that returns a "lost connection" error and can't be restored.
> + * Use this instead of apr_reslist_release if the resource is bad.
> + */
> +APU_DECLARE(apr_status_t) apr_reslist_invalidate(apr_reslist_t *reslist,
> +                                                 void *resource);
> +
> +
>  #ifdef __cplusplus
>  }
>  #endif
> 
> --- apr-util/misc/apr_reslist.c.old     2004-01-02 02:44:05.000000000 +0000
> +++ apr-util/misc/apr_reslist.c.new     2004-01-02 02:51:27.000000000 +0000
> @@ -396,5 +396,17 @@
> 
>      return reslist_maint(reslist);
>  }
> +APU_DECLARE(apr_status_t) apr_reslist_invalidate(apr_reslist_t *reslist,
> +                                                 apr_res_t *res)

see comments in PR 26050 about discrepancy in prototypes that seems to show an 
underlying issue; apps don't see apr_res_t, so some rework and testing is needed


Mime
View raw message