"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 > >> > > >> > > >
