[PATCH] dynamic providers

Jim Meyering jim at meyering.net
Sat Dec 18 10:26:03 UTC 2010


Jeff Darcy wrote:
> On 12/17/2010 02:51 PM, Jim Meyering wrote:
>> I've included below a 7-cset series that allows providers to be added
>> and removed dynamically.  This shows you what the interface will look
>> like.
>
> I've looked at the code a bit; here are the first few things that I noticed.
>
> (1) The lack of locking around provider addition and (especially)
> deletion is a deal-breaker.  I see that we have a refcnt field on
> providers, but it's never updated for requests that use it so the checks
> for it in proxy_delete_prov are meaningless.  Without that the code
> simply isn't safe.

"deal-breaker"?  I made no claim that it was complete.
The "FIXME" in a commit log title makes it quite clear that
the implementation is incomplete:

    add provider ref-counting; FIXME: partial impl. (i.e., no incr)

To think otherwise, perhaps you missed this part of my initial post:

    > There are caveats: to be done properly, this will
    > require reference-counting each provider and actually freeing one
    > only when we're sure no other thread is using it.
    > Likewise, the provider hash table will need protection
    > against corruption via concurrent modification.


> I don't think the code uses any of the provider
> fields after a back-end request is initiated, so we might not need to
> wait for those to complete, but
>
> 	(a) trying to guarantee that for every library to which we pass those
> 	fields, forever, is questionable from a maintenance POV;
>
> 	(b) that still leaves us vulnerable to initiation-phase conflicts with
> 	other threads;
>
> 	(c) queued replication jobs will make that even more complicated.

Are you arguing that ref-counting cannot work at all, or merely
that some hypothetical partial implementation would not be sustainable?

I have been considering alternative approaches that would be
easier to code and maintain:

  - allow only addition of providers, not deletion, but with some
      reasonably large static limit.  This is probably a non-starter,
      since even ignoring malicious abuse[*], an erroneous "client"
      script could easily send requests that would fill the table
      to the maximum.

  - use garbage collection rather than explicit "free" calls.
      Is there even a good multi-thread aware garbage collector for C?


More information about the iwhd-devel mailing list