On 04/07/2015 04:17 PM, Thiago Macieira wrote: > On Tuesday 07 April 2015 15:46:54 Jon A. Cruz wrote: >> Pushing out so that the hosting app can call an appropriate select() >> equivalent then push into the stack as needed can eliminate the need for >> internal threading and for odd sleep calls. This also frees us from the >> burden of trying to wrap mutexes, etc. Getting to a point where a single >> select() can do one watch for multiple stacks can make things very >> efficient. > > Hi Jon > > I'm not sure we can get completely rid of the locks. > > What happens if the application is multithreaded and calls our API from > multiple different threads simultaneously? > > If we don't introduce the IoTivity context, we will need locks. > > If we do introduce a context structure, we may be able to say "you lock" to > the application. >
Yes. I believe the latter is better for several reasons, including thread safety, testability, debugging, etc. At the least we can minimize use and clearly document things. This will also help avoid deadlocks such as the current code hits during the unit tests (hence the need for the testing deadman timer, etc.) -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com
