>> "You can easily have two unrelated library users in the same process - often without the main application knowing about the library at all. Make sure your library can handle that."
> Uh... this makes little to no sense
The canonical example here is that your application is using library A and library B and both A and B are using library C as a private implementation detail. You would think that this just works out of the box, but often it doesn't mostly because of global variables and other assumptions. I should probably include that example.
Thanks for your other suggestions - for most, I had something in the original text that I decided to cull to make the text shorter as it was already too long. Once the full series is done, my plan is to revise each blog entry in the series and then post another blog entry listing what changes I've made including giving credit (e.g. linking to your comment for changes inspired by it etc.).
Posted Jun 28, 2011 14:02 UTC (Tue) by crazychenz (guest, #56983)
[Link]
Got it. Thanks for the clarification.
Chenz
Zeuthen: Writing a C library, part 1
Posted Jun 28, 2011 20:55 UTC (Tue) by JoelSherrill (guest, #43881)
[Link]
This is actually a common thing to encounter when using existing libraries in a single process embedded system. Different threads may be completely independent logically but both use a library which has a single global state.
If you are lucky, the library keeps all this data in a structure so you can use what are often called "per task variables" in an RTOS. This adds the contents of a global pointer to the context of a thread. It is then switched in and out with the thread. RTEMS and VxWorks both have these.
In a similar vein, reusing existing libraries used to dynamically
linked, multi-process environments to a single process, statically linked environment can also lead to symbol name conflicts when global symbols have common names.