Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 03 Oct 2013 14:07:08 +0200
From: =?UTF-8?Q?Bj=C3=B6rn_Petri?= <bjoern.petri@sundevil.de>
To: <celix-dev@incubator.apache.org>
Subject: Re: Remote service using shared mem
In-Reply-To: 
 <CA+T-u8cnsBAxO6q_Ud8BgE9h8qjJevrrQK1kZNfzNWkv4irKOQ@mail.gmail.com>
References: <5213C63A.1050002@gmail.com>
 <E825BCB2-EAFD-4E97-88C0-B1BB1085506A@luminis.nl>
 <52150460.7070606@gmail.com>
 <CA+T-u8e2tvMgKdj9FjQ6h5ACQFmT11k8RpvKJ-Ci64HoW9fYEw@mail.gmail.com>
 <52356979.1040002@sundevil.de>
 <CA+T-u8fOd9TbY5W2h4PYxrLJzo1-mM09c3=CbOMEQ8TLio-Rqw@mail.gmail.com>
 <03fa0772516eaaab4c1fcf59f52f00e9@imap.sundevil.de>
 <CA+T-u8cs9Bioac7NwDFf3xuggRfSgBnKORrwwLJB34y_LE6QWQ@mail.gmail.com>
 <dbdb0588141d589373b66404ce2b8ecd@imap.sundevil.de>
 <CA+T-u8ccYmz15uZd8TP3LAZGW74MCTbrUs=+Bqay=jR6pZQ=eA@mail.gmail.com>
 <5238198D.8050209@sundevil.de>
 <CA+T-u8e4s4UuDbXk=wDZkhZ7+OSo7Z22E8ROQk5hSyD9DvdxVw@mail.gmail.com>
 <CA+T-u8eecxMJvwwuP=LZU9TXEkv09C3EZXtUFnOWCOfuGBs4nA@mail.gmail.com>
 <4f9dbca6c64a7583e34c4be4cab8eadc@imap.sundevil.de>
 <CA+T-u8fDDmRPwJjxbiqb8cLVbtq4cZxD5ar1FWGaBbejgPdq+w@mail.gmail.com>
 <52454D60.9030906@sundevil.de>
 <CA+T-u8ei8MpVZp8HtZy6E66+Gfcn5urm+gYUFRHB21XZYsmZcg@mail.gmail.com>
 <bc45451b45d3571b60b11abb2131a151@imap.sundevil.de>
 <CA+T-u8cnsBAxO6q_Ud8BgE9h8qjJevrrQK1kZNfzNWkv4irKOQ@mail.gmail.com>
Message-ID: <617379229e8f0bcdc85d3ed8fe429f1d@imap.sundevil.de>
User-Agent: Roundcube Webmail/RCMAIL_VERSION


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.
>>>
>>
>>