ccn-lite
ccn-lite copied to clipboard
cn-uofbasel
malloc: ccnl_prefix_to_path_detailed
ccnl_prefix_to_path_detailed() is used in a lot of places throughout the code. It basically just allocates (via malloc) a buffer, and passes it to ccnl_prefix_to_str_detailed().
Instead of relying on malloc in the core libs of ccn-lite (core, fwd,...), should we rather use a statically allocated memory block and call _str_detailed() directly, instead of _path_detailed()?
The benefit is: no malloc at all, so all the mandatory ccnl_free's() can be dropped. A disadvantage would be that in a multi-threaded scenario, the (global) statically allocated memory block needs to be guarded against concurrent (write) access. CCN-lite itself does not support multi-threading, but a CCN-lite API user might call functions in a multi-threaded fashion. I am sure we can find a solution for that without introducing mutexes, though.
Opinions, ideas?
for reference: https://github.com/cn-uofbasel/ccn-lite/blob/master/src/ccnl-core/src/ccnl-prefix.c#L557
I am sure we can find a solution for that without introducing mutexes, though.
You mean a lock-free memory allocator which allocates memory from a pre-defined memory block?
You mean a lock free memory allocator which allocates memory from a pre-defined memory block?
sounds like malloc to me (:
the first thing would be to evaluate, if there are any calls to _path_detailed() from API functions. If not, then there's no problem at all.
sounds like malloc to me (:
I'm not an expert on lock-free memory allocation, but I've thought it's a bit more complex (see also Scalable Lock-Free Dynamic Memory Allocation)
the first thing would be to evaluate, if there are any calls to _path_detailed() from API functions. If not, then there's no ürpblem at all.
git grep to the rescue
tl;dr i'm happy that you address potential issues with multi-threading and we should keep this in mind
We've discussed the parallel access issue during our last project meeting in Hamburg and the corresponding workaround. Honestly, I'm still not convinced that this is the way to go and I think ccn-lite in the long run should support multi-threading/parallel access.
Saying that, no matter how we (or whoever is addressing this issue (and related topics)) handle the malloc situation, we shouldn't make things worse if at some point somebody wants to add support for multi-threading.
and I think ccn-lite in the long run should support multi-threading/parallel access
do you mean the ccn-lite core (or forwarding daemon) should support multi-threadding? Or should the user API just be thread-safe?
do you mean the ccn-lite core (or forwarding daemon) should support multi-threadding? Or should the user API just be thread-safe?
From the perspective of RIOT, making the forwarder multi-threaded is probably a no-go. Making the API calls thread-safe is however necessary, be it for RIOT or Linux/OSX
From the perspective of RIOT, making the forwarder multi-threaded is probably a no-go. Making the API calls thread-safe is however necessary, be it for RIOT or Linux/OSX
The API needs to be thread-safe. Basically every essential data structure is part of struct ccnl_relay_s which will make this a cumbersome endeavour.