On Tuesday 17 February 2015 11:13:42 Keane, Erich wrote: > Making the C library thread-safe is giong to be quite an undertaking, > potentially requiring a ton of re-design work and changing a good number > of the APIs (particularly if reentrance is something we want).
I know. But I feel it's quite required. > As far as having C++ stop spawning threads, they are quite required > unfortunately. Unless we want our customers to be required to run the > message pump, we need a thread to continuously call OCProcess. I also understand that, but asking the user to run the message pump is exactly what I'd like. We can provide a convenience for users that want a simpler application, but I feel that any complex application will already have a message pump (main loop, event loop, whatever you call it) of its own and we should instead integrate with that. > Removing the threads spawned upon message retrieval wouldn't be that big > of a deal, however it would cause a few problems. Note that each of > these is called in the C-context, so it would result in user-code > freezing the message pump and likely introducing a number of delays in > message receiving. Right, but that's exactly what we're asking for in the C library anyway, so what's the harm? If threads are necessary to do the work of a request, then the user should spawn a thread to do said work, as opposed to forcing a thread on the user. It's possible that the user's application is not thread-safe, so they have no option but to run everything in the same thread. > I am curious in what way you find the C++ implementation to not be > thread safe? It should be safe to call the C++ implementation from a > number of threads, and we have an example that does just that. Any part of it? Including OCProcess, OCPlatform, etc? I simply can't see how the C++ layer can be thread-safe if the C layer isn't. Unless you're about to tell me that the C++ layer doesn't use the C layer at all... Think of an application that uses two independent libraries that each want to use IoTivity. The application doesn't know (and doesn't care) that the two libraries use our libraries. Our libraries must work for multiple consumers in the same process, whether they are used from the same thread or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
