On Tue, 2015-02-17 at 11:27 -0800, Thiago Macieira wrote: > 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. >
If thats the case and what is decided, we can definitely do that part quite easily. An API would have to be added, but if it is decided, we can definitely do that. I'd like to do it fairly similarly to how boost::asio does message threads. > > 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 could go either way on it then I guess. I liked the idea that the C++ stack was less error prone and was closer to 'just works' and hid a lot of the C 'gotchas' that we have. > > 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... The C++ layer controls access to the C layer with mutexes, essentially forcing access to the C layer to be serialized. It doesn't solve re-entrance problems, but it should be thread safe at least (though not entirely taking advantage of the threading). > > 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. > The concern there is that both libraries would potentially be running their own Process thread, which would cause a massive performance hits. At the moment our C++ thread SHOULD work in exactly this case however.
