Oliver.
Have you got a chance to take a look at the materials?
If yes, what do you think on it?
Yours sincerely,
George.
[EMAIL PROTECTED] ?????:
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.
