[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