On Tuesday 17 February 2015 11:35:33 Keane, Erich wrote: > > > 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'm not disputing the making of an easier API. I'm all for that. But I do question using that as an excuse for having a bad API in C. If we're going to have a C API at all, it should be good enough to stand on its own. And that's why I am asking to make it thread-safe or, at the very least, reentrant if the functions are called with different objects. > > > 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). Which reentrancy problems are you thinking of? Let's make sure we're talking about the same thing when we say "reentrant". The common definition of it is that the function can be re-entered simultaneously from multiple threads as well as re-entered from the same thread, so long as the objects passed in parameters are different. That usually has two consequences: 1) if two threads independently call the same function on different objects, they should work and not interfere with each other. Any shared global state needs to be protected by a mutex. 2) if the same thread calls back into a function that is already running, the function behave as expected (e.g., not deadlock). That's usually accomplished by always dropping locks before calling out to user code. I'm mostly thinking of #1 here, but #2 also applies there's extensive use of callbacks, like we do. > > 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. Why would there be performance problems by running multiple threads that handle sockets? If we decide to use a common thread for all users, behind the scenes, that's fine. But it should be transparent to all users. More importantly, the user should not see this thread and should never get callbacks called in this thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
