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 <[email protected]> > > 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 <[email protected]> >> >> 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
