celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: Remote service using shared mem
Date Thu, 03 Oct 2013 09:59:52 GMT
Hi Bjoern,

I have some problems with the discovery now. If I try to stop the discovery
bundle, it tries to join the discovery thread, but somehow the lock isn't
released and the thread doesn't exit.

Looking in the code, the discovery_stop now has an unlock directly followed
by a lock. This seems to be the problem. Did a small error sneak in? Or is
there some reason for the unlock/lock?

I'll do some more testing later on this week, so I'll get back to you :)


2013/10/2 Björn Petri <bjoern.petri@sundevil.de>

>
> Alexander,
>
> I updated the rs shared memory implementation to
>
> (1) use System-V shared memory routines instead of ones from APR,
> (2) make use of your install_bundles macro,
> (3) perform some necessary cleanup when the exported service is stopped
> (This is also missing in the "standard"-rsa implementation). See
> remoteServiceAdmin_**removeExportedService function for details,
> (4) get rid of the linking of the example_proxy against the rsa_shm,
> (5) and fixed some minor bugs.
>
> looking forward to your feedback,
>   Bjoern
>
>
>
>
>
>
>
>
>
> Am 2013-09-27 16:11, schrieb Alexander Broekhuis:
>
>  2013/9/27 Björn Petri <bjoern.petri@sundevil.de>
>>
>>  On 09/18/2013 06:29 PM, Alexander Broekhuis wrote:
>>>
>>>  I checked it, and there are some small leftovers in the code. The proxy
>>>> still includes the rsa and also links with the library.
>>>>
>>>>
>>> How do you want to get rid of this dependency? The proxy needs to include
>>> definition of the remote_proxy_service as well as the rsa does. Do I miss
>>> something?
>>>
>>>
>> Since the proxy now uses the function pointer and only the service struct
>> of the RSA it only needs the header files (as far as I can tell). Also,
>> with the concept of bundles, and Celix not supporting code-sharing at this
>> point, bundles (actually the library in it) should never link to a library
>> of any other bundle.
>> Libraries are loaded locally, so the symbols aren't shared with others. So
>> this means that if you link with another bundle, at runtime there will be
>> unresolved references. Hence the need for services (structs with function
>> pointers) etc.
>>
>
>


-- 
Met vriendelijke groet,

Alexander Broekhuis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message