Re: [boost] yomm2 - open methods

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
data.

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
atomically swapped).

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
behavior...