On 02/24/2015 11:06 AM, Thiago Macieira wrote: > On Tuesday 24 February 2015 10:54:16 Keane, Erich wrote: >> The idea of the extra layer of abstraction would be to make for an extremely >> simple implementation, rather than trying to re-invent the wheel (making >> ANOTHER custom mutex wrapper). > > I understand the concern of reinventing the wheel. However, there's a reason > everyone does it and we have that reason affecting us. > > If you can find a simple, existing implementation of this wrapper we could > use > by including into our source code, we should go for it. But I'd rather avoid > linking to another library (GLib, APR, etc.) for it if that's all we need > from > that library.
Another thing to consider is the route that OpenSSL has taken. They have exposed a few calls to register mutex/thread handling, but don't use any internal implementation themselves. The hosting app is then free to initialize and configure things as appropriate. IoTivity could expose a simple thread support API like OpenSSL does, and include a default implementation if a system/application does not need anything custom. Or... we could at the least ensure that our internal wrappers are used in a way such that a public API for locking can be exposed. That sounds like a helpful separation. -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com
