Thank you for your reply, Oliver.
Briefly speaking the solution to the problems you have mentioned looks
like this:
1. take a loot at the first picture here:
http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works
2. Pointer 1, 2... are vptrs
3. The idea is that each module, library (.so) has a row of vptrs, when
it is required to make a dynamic binding this row is going to be copied
to the similar one, the new vptrs are applied to the new row of vptrs,
the previous, old row is unchanged. Then the shift looks like
incremental lock of integer value which is the version of this module
(.so). So it means that these threads which execute the code inside the
'old module' they are unchanged, and the new code is going to be
executed in case we will have got the new call to the functions of the
module. It might have been said it does not answer the question, since
there might be some loops which needs to be reloaded also, though I
believe it does, since this tends more to the architecture than to
linkage already :-)
This is quite brief and uncertain explanation. In reality it does not
look like this. More details could have been found here:
http://docs.georgeshagov.com/twiki/tiki-index.php?page=Matrix+Linking+how+it+works.
I hope you will find worthy the reading.
In case of questions do not hesitate to ask.
Yours sincerely,
George.
Olivier Galibert ?????:
On Fri, Nov 23, 2007 at 11:49:03AM +0300, [EMAIL PROTECTED] wrote:
[Changing the _vptr or C equivalent dynamically]
I would like the community would have considered the idea. I am ready to
answer all the questions you might have.
Changing the virtual function pointer dynamically using a serializing
instruction is I'm afraid just the tip of the iceberb. Even
forgetting for a second that some architectures do not have
serializing instructions per se, there are some not-so-simple details
to take into account:
- the compiler can cache the vptr in a register, making your
serialization less than serialized suddently
- changing a group of functions is usually not enough. A component
version change usually means its internal representation of the state
changes. Which, in turn, means you need to serialize the object
(whatever the programming language) in the older version and
unserialize it in the newer, while deferring calls into the object
from any thread
- previous point means you also need to be able to know if any thread
is "inside" the object in order to have it get out before you do a
version change. Which in objects that use a somee of message fifo
for work dispatching may never happen in the first place
Dynamic vtpr binding is only the start of the solution.
OG.
