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 Mon, 16 Sep 2013 20:13:21 GMT
2013/9/16 Björn Petri <bjoern.petri@sundevil.de>

> I agree, Pepijn told me that Erik Jasman has already done quite a lot of
> work to achieve this.
> Maybe we could contine with his approach?!

Yeah, I'd like to see that code. Not sure if Erik has already shared

>  When testing "remote-services-shm" and stopping the "example" bundle, the
>> discovery tries to deregister an entry, this results in a call to register
>> which somehow fails with an segfault. Maybe I am missing something, but
>> there is no removal anywhere. How is this supposed to work? Btw, before
>> the
>> segfault the following error is printed:
>> DISCOVERY: Endpoint for example, with filter "(null)" removed
>> DISCOVERY : discovery_registerSHMService : encoding data from HashMap
>> failed
> As the registered services are held as a hashmap (based on netstring) in
> the shared memory, the plan was to do a remove instead of a put if the
> value is set to NULL. Probably it is a good idea to rename the
> discovery_registerSHMService when I use it for registering and
> deregistering.

While at some points I get that some method like this might make sense... I
always prefer code readability. Using a register method to do an
unregister... Just doesn't make sense to me. So please do make a
unregister/deregister method for the deregister use case. Code wise you'd
end up with almost the same code, but there is no NULL check and 2 flows in
one method.

> I have problems getting the code to run on my Mac. I run into several
>> segfaults, so this needs some more testing before I can commit it.
> I will take care about the issues mentioned above and provide an updated
> patch.

I think there are some more problems beyond the ones mentioned, but I need
to test this a bit more. Looking forward to a new patch!

Met vriendelijke groet,

Alexander Broekhuis

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