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 Thu, 05 Dec 2013 19:03:30 GMT

Hi Alexander,

thanks for your feedback. Concerning your issues:

* I am fine with replacing semtimedop again through semop, as the 
function calls are almost identical, I can do that right away.

* Same for the JSON format changes. As far as I remember, there is only 
a line per function which specifies the JSON format.

I'll provide you with the changes asap. Let me know when something else 
should be done.

Regards,
   Björn




Am 2013-12-05 17:17, schrieb Alexander Broekhuis:
> Hi Bjoern,
>
> I'm now trying to apply the patch and have some new issues, I've 
> added some
> remarks in between:
>
> * It is created against an older revision, some small changes that 
> easily
> can be fixed.
>   For a final patch I'd like this to be solved, but isn't a big 
> issue.
> * It now uses "semtimedop", which is a GLibC function (and not posix) 
> so
> now it doesn't work on OSX.
>   While I think we should work towards a broader support with these 
> kind of
> things, I can live with the first version being Linux (GLibC) only. 
> But
> this does mean I cannot test it at this moment.. So someone should
> definitely still do this (Pepijn?)
> * Calculator Endpoint/Proxy uses the older format for the JSON data 
> (which
> is incompatible with the Amdatu RSA).
>   This is a small change in the encoding/decoding, but isn't a big 
> issue.
> * The SHM RSA uses setHandler/setCallback instead of 
> setEndpointProperties.
> The existing HTTP RSA doesn't use these yet.
>   At this moment this breaks the Calculator example when used with 
> the HTTP
> RSA. Probably not that difficult to port back to the HTTP RSA. I 
> prefer the
> newer method, so definitely in favour of applying those changes to 
> the HTTP
> RSA as well.
>
> Some other remarks/updates not yet mentioned on this list:
> Yesterday we already talked about how to donate this code. Since this 
> code
> introduces new bundles it makes the most sense to handle this using a 
> Code
> Grant and IP Clearance.
> We already discussed that Pepijn is willing to do the paper work, so
> hopefully it al doesn't take that much time.
>
> So to summarize (in order):
> 1) We need a working set of bundles (at least tested on Linux, 
> preferably
> on OSX as well). Existing code should still work as well.
> 2) After that a code grant with Issue number and MD5 sum needs to be 
> filled
> in and filed.
> 3) Finally the IP Clearance should be handled.
>
> I have some time to do some work, so I can help out a bit. For now 
> I'll
> work on getting the setHandler/setCallback method in the HTTP RSA as 
> well,
> if that is in place, ideally you shouldn't need to update those for 
> the SHM
> RSA.
>
> Anything I forgot or overlooking?
>
>
>
> 2013/12/4 Björn Petri <bjoern.petri@sundevil.de>
>
>>
>>
>> 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