Subject: Re: [boost] yomm2 - open methods
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2018-01-24 16:30:21
> A better way is to define an implementation
> macro that takes the namespace as a parameter,
> and then force __COUNTER__ to be expanded once
> by the outer macro. (BOOST_PP_SUB has a pretty
> low upper maximum.)
Ah, good idea, thanks.
> My opinion is that dlopen/dlclose should be
> exactly as safe for multimethods as they
> are for normal functions.
I prefer to call them "open methods", unless the context requires insisting on
multiple dispatch. A study (see here
https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice) shows that
multiple dispatch is very rarely needed. I don't want potential users to think
"multimethods, nice, but I don't have any need for that", and miss on the value
of *open* methods with one virtual argument.
But of course you are free to use the words you want ;-)
> It might be better to assume that rebuilding
> the tables is rare. Then you can build a completely
> new table and swap it in atomically.
I expect it to be rare and I *know* that it is costly.
I may be able to pull this off at the cost of some redundancy in the dispatch
As of now, there is a global structure, shared by all methods, which contains
just three words: a multiplier, a shift factor and a vector of "words" (either
pointers or ints) that is a mixed bag of things (a collision free hash table,
the equivalent of a vtable for each class, dispatch tables and strides for
*multi* methods, slots occupied by each method).
Those three words can be folded together and accessed via a pointer (to be
Each method contains a pointer inside that global vector, to the first slot
(followed by the second slot, a stride, a slot, etc for multi-methods). That's
the problem: one pointer per method.
But I think I can rearrange the dispatcher to work with just the pointer from
the method. I will have to replicate the content of that global structure for
each method, before the first slot.
Then a method could be swapped atomically. All the methods would *not* flip
to the new table atomically, but I think that this may still give the correct
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk