celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Björn Petri <bjoern.pe...@sundevil.de>
Subject Re: Remote service using shared mem
Date Wed, 04 Dec 2013 17:07:30 GMT


I updated the functionality of the discovery component to ensure that 
all threads perform its update routine, when a service was added/stopped 
or the discovery bundle is stopped.

I would be happy if you find the time to give it a short check.

Regards,
   Bjoern





Am 2013-10-03 14:07, schrieb Björn Petri:
> Hi Alexander,
>
> introducing the lock in the discovery_stop function was done with
> purpose. The unlocking and locking should enable all
> discovery-polling-threads to update their local list of services and
> in the case of the stopping discovery bundle it should allow the
> thread to leave it's loop (the loop control variable should be set to
> false before performing the unlock and lock). So, it should actually
> not wait on the join - I'll take a look at the code and check what is
> going on there.
>
> Regards,
>   Björn
>
>
>
>
> Am 2013-10-03 11:59, schrieb Alexander Broekhuis:
>> 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.
>>>>
>>>
>>>


Mime
View raw message