Re: [boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-19 03:02:07

Robert Ramey wrote:

>>>> Besides, I don't understand how you
>>>> can "inhibit loading of DLLS". Say, one thread has created an
>>>> archive and does something with it. Some other thread tries to open
>>>> DLL. What should happen? Should  that other thread get "sorry, some
>>>> archives are open" error? And what
>>>> will  it do?
> 
> I havn't considered it in detail but its easy to consider using a
> semaphore
> (even though I'm sure there are better solutions).  Semaphore is
> incremented
> each time an archive is opened.  DLL Loading/Unloading code blocks until
> reaches zero.  

All DLL loading/unloading? Remember we can't check if DLL uses serialization
until we load it.

>> 1. A program creates an archive to read from network connection.
>> Network connection is never to be closed.
>>
>> 2. A command arrives via connection that requires loading a plugin.
>>
>> 3. The plugin has BOOST_CLASS_EXPORT, so attempt to load it crashes.
>>   We have two possibilities:
>>
>> 3a. Since the exception happens when you modified serialization
>> tables, and that happens in static initializer, you cannot catch the
>> exception anywhere in the plugin code. Since the plugin (on Unix), is
>> opened with C function dlopen, it's not clear if the exception will
>> propagated across that C function. So, the whole application might
>> crash.
> 
>> 3b. Assume we checked if archives are opened before calling dlopen.
>> Actually, we cannot, because we don't know, generally speaking, if the
>> plugin uses BOOST_CLASS_EXPORT or not. But assume we somehow know
>> this and figured that we can't load the plugin. Now:
>>
>>      - we can't close the network connection, because it waits for
>>        further commands
>>      - we can't load plugin because some archive is opened, so we can
>>        do the previous command we've received
> 
> I'm not sure I get all this.  In general the recieving machine would have
> to have the code for doing the loading installed before the archive is
> opened. It would seem to me you would need to break this in to two
> transations. One communicate which DLL might be necessary - passing the
> DLL which contains
> the right code.  Then close the archve, load all desired DLLS and
> construct a new archive for the "real" data which might be serialized from
> one of the previous DLLS.

So, you need to split each request in two parts: first the allows the server
to determine which DLLs to load, and another one that gives the other data.
You'd need to break connection between those two steps which does not look
all the nice.

And further: say you have a server that talks with 10 clients at the same
time using some archive class. One client requests an operations that needs
loading a DLL. Do you expect that:

1. Server will stop accepting new connections
2. Wait till 9 other connections stop
3. After that, load the DLL?

or simply that all connection will be dropped?

>> This is over-generalisation. Clearly, new BOOST_CLASS_EXPORT
>> statements won't break anything.
> 
> The will if they are included in a DLL that is unload in the middle of the
> saving/loading of
> an archive which contains classes of the indicated type.

I suppose that any use of My_class with simultaneous unloading of DLL that
defines that class is so risky, that you should not take special care about
this in serialization at all. If users unload DLL while instances of the
class are still around, they already have a bug.

BTW, on-demand loaded DLLs are not essential to this discussion.
BOOST_CLASS_EXPORT becomes static object, right? C++ standard says that
static initializer constructor can be executed right before the first
function in some module is called. So, you can get unexpected
BOOST_CLASS_EXPORT executions even without on-demand loaded DLL. Again --
you read something from archive over network, and take some action.
Accidentally, you call a function in new module and BOOST_CLASS_EXPORT is
executed.

Now, on Unix all static initialisers are run when the program is first
loaded, so I probably should not care if some other users run into
problems.

- Volodya