If you put a patch together for that, I'm sure it'll be popular :) Another thought-- Could we perhaps expose these operations in a way that the implementer can specify? Basically, have a configuration step pre-Init that would allow the user of our stack to specify their own mutex/threading library instead?
This would likely also make the need for _singlethread versions of things unnecessary, since the OSAL stuff could be handled by the implementer (plus a solid default implementation). The nice part of this is we could potentially introduce atomics in c ++11/C11 code, or on platforms where this would be beneficial. Additionally allowing the C++ stack to use std::thread (or boost thread!) would potentially be a popular function. On Tue, 2015-04-07 at 22:09 +0000, Light, John J wrote: > "most of the developers on this project have been IN the CCF code as well" > > I'm clean, and I'll be glad to do it. > > John > > -----Original Message----- > From: Keane, Erich > Sent: Tuesday, April 07, 2015 3:06 PM > To: Lenahan, Charlie > Cc: iotivity-dev at lists.iotivity.org; Macieira, Thiago; Light, John J > Subject: Re: [dev] OCProcess & event loop (was: build sample application for > sensors) > > In that case, we also have to be careful that we don't infringe on our own > copyright as well. Unless CCF is open-sourced with a compatible license, we > risk getting Intel copywritten code getting into the stack, since most of the > developers on this project have been IN the CCF code as well. > > > On Tue, 2015-04-07 at 22:01 +0000, Lenahan, Charlie wrote: > > Mutex/thread?ing isn?t that difficult as we?ve done that for CCF on > > linux/android/ios/windows/winrt. > > > > > > A ThreadPool is different can of worms, which is a part of the code > > that I haven?t had time to look into, But a cursory glance it seemed , > > that the connectivity layer isn?t really creating oodles and oodles of > > jobs, which would necessitate a threadpool. > > > > It seems to just start a handful of threads at start up and run until > > program exit. > > > > If that is the case then a osal wrapper around thread create, etc. > > would suffice. > > > > On 4/7/15, 5:48 PM, "Keane, Erich" <erich.keane at intel.com> wrote: > > > > >I agree, glib2 has been a bit of a pain. Implementing a > > >mutex/thread/threadpool in a multi-platform solution is quite a task > > >however, and I would much rather find a solid library to do these > > >things rather than implement and maintain them ourselves. > > > > > > > > > On Tue, 2015-04-07 at 21:46 +0000, Lenahan, Charlie wrote: > > >> I'd throw my hat in the remove glib camp too. > > >> > > >> On 4/7/15, 5:28 PM, "Light, John J" <john.j.light at intel.com> wrote: > > >> > > >> >" or since we're using glib anyway, GMainLoop?" > > >> > > > >> >I would prefer we move in the direction of weaning ourselves from > > >> >glib rather than using it more, since we are aiming at tiny processors. > > >> > > > >> >I believe there are simple solutions to the event loop issue that > > >> >don't require hammers. > > >> > > > >> >John > > >> > > > >> > > > > >
