For C anyway, why not just provide contexts?
OCCtx *ctx = OCCtxInit(config); if(NULL == ctx) return error(); // ... OCProcess(ctx); // ... OCCtxDestroy(ctx); ...and so on. This unfortunately is a breaking change, but it gives us a way to eliminate shared global state (i.e. global variables) and can be used whether there are coroutines, multiple contexts, threads, or not. -Jesse On Tue, 2015-02-17 at 21:04 +0000, Hudson, Douglas wrote: > That said, given the thread-safe layers above and below the C stack (the C++ > layer and the new CA layer, respectively), it would be nice to make the C > stack thread-safe. > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bounces > at lists.iotivity.org] On Behalf Of Hudson, Douglas > Sent: Tuesday, February 17, 2015 3:54 PM > To: Macieira, Thiago; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Ripping out the threads > > A little bit of history regarding the C stack. It was implemented first and > wasn't originally intended to be thread-safe. The initial thought was that > that would allow it to run efficiently and have less of a footprint on a > bare-metal micro with no RTOS (i.e. single threaded). If an app wanted to > use threads, then the app should provide a mutex based on its OS/RTOS and > serialize access to the C stack. The C++ layer did this for devices that > weren't resource constrained. > > Early implementation goals for the C stack were: > - to be as small as possible so that we could run on a wide variety of > constrained devices > - RTOS/OS agnostic > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bounces > at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Tuesday, February 17, 2015 3:27 PM > To: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Ripping out the threads > > 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 > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
