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 >> > >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5859 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150407/709ccf27/attachment.p7s>
