Has anyone thought more about this issue? Is the idea that the app will have a run loop and give the stack a handle/function pointer , so that it can signal the app to ?wake up? I have stuff you can now process?
On 4/7/15, 7:22 PM, "Jon A. Cruz" <jonc at osg.samsung.com> wrote: > > >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 >_______________________________________________ >iotivity-dev mailing list >iotivity-dev at lists.iotivity.org >https://lists.iotivity.org/mailman/listinfo/iotivity-dev
