On Tuesday 07 April 2015 15:14:13 Keane, Erich wrote: > Another thought-- > Could we perhaps expose these operations in a way that the implementer > can specify? Basically, have a configuration step pre-Init that would > allow the user of our stack to specify their own mutex/threading library > instead?
Are you talking about a step during IoTivity's configuration? Or at the load time of the application? If you meant the latter, I recommend against that. This is exactly what libdbus-1 did up until 1.2 or so: you had to initialise the threading support by setting a bunch of callback functions so that DBusMutex and DBusWaitCondition would work. That was a disaster, for two reasons: * applications either forgot to do it or did it incorrectly, resulting in all manners of funny (not!) thread-safety issues * if you loaded two libraries using libdbus-1 and they happened to call the setup function twice, then libdbus-1 would switch from one backend to another, resulting in another set of funny issues -- which you'd usually only catch when running in the user's system, when a Qt application loaded the Gtk style plugin, which loaded caused GConf to try and connect to D-Bus... And the whole reason D-Bus tried to do it was so that libdbus-1 would not depend on libpthread. We don't need that. > This would likely also make the need for _singlethread versions of > things unnecessary, since the OSAL stuff could be handled by the > implementer (plus a solid default implementation). > > The nice part of this is we could potentially introduce atomics in c > ++11/C11 code, or on platforms where this would be beneficial. > Additionally allowing the C++ stack to use std::thread (or boost > thread!) would potentially be a popular function. I'm not against either, but that raises the bar of compiler support requirement again. Remember we're debating whether C99 is acceptable. C11 is not a discussion... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
