OK, I’ve no idea if this is the right place to post this, but here goes (mods, please edit, move to a better place if you want to)
I’ve hit a snag. My © library (which is using JUCE under the bonnet to do Serial control of a USB device) leaks when the calling app is terminated.
Evidently, Windows (the only bit I’ve worked on so far) discards the library when the app is terminated (or crashes?), and none of the lovely underlying JUCE code gets a chance to shutdown / clean-up. FOP it’s gone! I don’t know how other OSs deal with this.
I really don’t want to add a special command to close the library, as that could mean users having to change their code.
There must be a (cross-platform) way for a C Library to know that it’s about to be terminated / unloaded / thrown away (I thought catching a SIGTERM?) but I can’t find one - In case you’re wondering, inheriting from DeletedAtShutdown doesn’t work (but perhaps WIBNI if it included whatever results from this discussion?.. but as it works fine, I won’t hold my breath)
But I can’t figure it out. How does a library know it’s about to be unloaded? Any ideas anyone?
More info for the morbidly curious
(no posting Youtube videos of SpittingImage please, Jules!)
Don’t laugh! I’m writing a JUCE implementation of a Raspberry Pi library, WiringPi GPIO control for an RTk.GPIO - A Generic USB (RaspberryPi look alike) GPIO device that’ll work on practically anything (Windows/OSX/Linux / perhaps even iOS/Android? ).
Ryanteck’s device is a USB Serial Interface which takes simple commands and turns them into GPIO commands - Set this line high, read that switch, drive that stepper motor, make this tristate… etc
I’ve based my code on om ohm productions excellent code (because it was the first one I tried, it worked for me and importantly, I could understand how it worked. Thanks, guys!) - I’ve added some sneakiness to search for the USB device(s) automagically, and allow you to drive one (eventually more than one) wrapped their class in another class , and then wrote a library whose header is Identical to WiringPi’s published one (I’ve thought of a couple of specialist additions to extend functionality, but not break old code) - but essentially no code changes for anyone wishing to use their app on anything.
When done, I’ll be posting the code for all to see (and laugh at) At the moment the worst bit is my hackery to locate any/all RTk.GPIO devices by blundering my way through the Registry, (oh, and that it leaks like a sieve when an app terminates, obviously) .