Milter-greylist

> 
> We do a rought lock of the whole list during the operation, and it
> can be improved. Locking the individual entry seems the way to go,
> but this means adding a refcount so that it can be detached from the
> list (by config reload) during operation, and freed by the last
> user when refcount drops to zero.
> 

What about the following?

The config_load() creates a totally new ACL list not relaying on any existing data
(no locking is needed than).
The ACL list has his own lock and associated reference count
which is initialized by the config_load().
Threads created after new configuration will start using this ACL list.
Old threads when they finish their job will release the lock of the old ACL list 
and the last old thread frees the list as the reference count reaches 0.
So old threads and new threads will use different ACL list as well as different locks.

The same logic may be applied not only to the ACL list but the full configuration,
as the ACL list is only part of the configuration data.

If we go further with this logic no need for reference count for the ACL list,
the reference count of the configuration should be used since one configuration has
exactly one ACL list. Part of freeing up the configuration is freeing up its associated ACL list.

Oh, by the way no ACL lock is needed at all if the ACL list is not modified after loading the new configuration!
(I am just thinking further as I am writing this e-mail)