[Vortex] [PATCH] fix vortex_channel_new prototype

[Francis Brosnan Blazquez]

> Hello,

Hi,

> Francis Brosnan Blazquez wrote:
> > Thanks for the patch, it is now applied since the profile parameter
> > usually receives a static string. In the future, if you find
> something
> > that would require an API breakage to improve the project you could
> > consider using a change notification [1].
> 
> I'll use that link if I have further API changes.

Good...

> > I'm currently in the middle of a general change to allow the library
> to
> > store all its context into a structure that will solve some dll
> issues
> > in windows. I hope to review the rest of pending patches soon.
> 
> I don't have any DLL issues apart from the axl_calloc/free that have 
> been patched a few days ago. Could you explain (briefly) what will be 
> stored in that context please, 

Sure Amiaux. The way turbulence [1] is extended, is to provide a module,
loaded at run time where all the particular profile code is placed.
Under Linux the code is working properly but we found a funny issue
while moving turbulence to windows.

The way global module private data from DLL is handle [2] makes each
process to have its own copy (the DLL code is shared but the private
data not). Until here everything is fine. However this behavior is also
extended to .dll code loaded with LoadLibrary.

Here is the situation:

   - turbulence.exe depends on libturbulence.dll and libvortex.dll. It
starts, owning a local copy (initialized by the corresponding
vortex_init and tubulence_init) for all private global variables owned
by each vortex and turbulence module (that its, all its state).
 
   - now, turbulence.exe loads all modules available at the configured
directories, for example, mod-test.dll, which also depends on
libturbulence.dll and libvortex.dll.

   - the windows loader found libturbulence.dll and libvortex.dll
already loaded by the process (turbulence.exe) and reuse the references,
but, all global state from that libraries (even knowing its is the same
process) is not shared, creating a new independent local copy for the
private global data for both libraries.

   - at this point, all configuration done by mod-test.dll is not
perceived by the calling process (turbulence.exe) making all
provisioning to be isolated, and therefore, not available.

The result is that, under linux, all initialization done and the state
associated is shared across the process, including modules loaded with
dlopen (which seems reasonable), but, under windows, due to some
uncertain security properties this do not work if the module is loaded
at runtime. It seems it is handled like a different process.

We have found several solutions but all of them are compiler-specific or
relay on the current DLL format (which apart from considering its real
application [3], they could start to fail in the future).

This is because we are changing the way these global private module
variables are stored, to use a single object which could allow us to
"transfer" the library state to the module loaded. 

The change introduced won't include any API change, it is an internal
change.

> maybe current patch can be previewed online ?

Sure, all changes applied to the vortex [4] and turbulence [5] are
available through subversion.

Cheers!

[1] http://www.turbulence.ws
[2]
http://mirrors.zoreil.com/webclub.kcom.ne.jp/ma/colinp/win32/dll/use.html
[3] A proposed solution is to access to the *_imp_foobar variable
through a define. The main problem to this approach is that all global
variables are hided behind the module API. This would require a redesign
that do not follow our coding style.
[4] https://dolphin.aspl.es/svn/publico/af-arch/trunk/libvortex/
[5] https://dolphin.aspl.es/svn/publico/af-arch/trunk/turbulence/

> Bye,
> AMIAUX Benoit
> 
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.