MJ, We will absolutely share. Erich is working with someone on another team who has solved these problems before on Android, Linux, Win32, WinRT and iOS to create a portable solution. His plan includes validating on each platform that he has available and then putting them up for review.
Thanks for the Tizen reminder. We should loop Martin Xu (or someone from the Tizen team) for guidance on Tizen. Other than you, who else in your group would you like us to invite to the gerrit review? Pat From: MyeongGi Jeong [mailto:[email protected]] Sent: Thursday, April 16, 2015 7:09 AM To: Lankswert, Patrick; iotivity-dev at lists.iotivity.org Subject: Re: RE: [dev] glib Dear Pat & Erich, I agree with your opinion that we require a light weight thread library in c stack to support multi-threading. and it will be good if RI layer also adapt multi thread model for concurrency and synchronization. As you know , uthreadpool.h & u_mutex.h file are the wrapper which separated glib from the source. Please share us the alternatives and design that you are planning to implement so that we can provide our inputs. And let us know if you require any help. And, I added some comment in-line.. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Lankswert, Patrick<patrick.lankswert at intel.com <mailto:patrick.lankswert at intel.com> > Date : 2015-04-15 21:39 (GMT+09:00) Title : RE: [dev] glib MJ, Answers are inline. From: [email protected] <mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of ??? Sent: Wednesday, April 15, 2015 7:24 AM To: iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] glib Hi, everyone. I'd like to say on the current CA aspect, CA uses 'threadpool', 'thread' and the 'mutex' of 'glib' to synchronize multi-thread for rich devices. To avoid license issue, CA and 'glib' linked dynamically. [PCL, 2015-04-15] Yes, this works for Ubuntu, but may not everywhere. >> Android and Tizen also. And forArduino, multi-thread model doesn't support. But for the future, if we consider other platforms, it maynot be true.. @mj I think multi-thread running model should be supported for rich devices to utilize device resources fully. The number of threads can be configurable for the device, [PCL, 2015-04-15] I cannot see how limiting the thread pool in CA would work. Since many parts of CA grab a thread and keep it, it looks like limiting the number of threads will only cause initialization failures or deadlocks (waiting for a thread in the pool to free) when the thread pool is exhausted. >> In the API, CAResult_t u_thread_pool_init(uint32_t num_of_threads, u_thread_pool_t *thread_pool), we can set the # of threads using num_of_threads. @mj And lite device operated by RTOS doesn't need glib dependency, it can run with single-thread model. [PCL, 2015-04-15] Why would you want them to run single-threaded? A number of RTOS have threading. >> I mean, lite devices on RTOS are likely to operate with 'single-thread' model. @mj The 'glib' can be removed if we find any alternative as we already have wrapped around 'glib'. [PCL, 2015-04-15] glib is a rich and valuable body of code. glib is a great framework for general purpose linux environments and I would encourage its use over reinventing the functionality. It is not a bad choice for embedded linux environments if you can avoid the licensing issues. It is just a poor choice for platforms that do not provide it natively. 1.7-3MB is a big hit when you have to bundle it with your application in order to support three interfaces. These are considerations that need to be taken into consideration when binding to an external library. Please remember for example that many (most?) Android and iOS application that leverage native development libraries bundle all the architectures (ARM, ARMv7, x86, etc) in their download. I have not seem the ARM version of glib, but the x86 version if 1.7MB. Multiply that times three and you are requiring 5MB download for glib before you add our libraries. In general, if you want to build portable code, you need to be very careful about what you depend upon. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com <mailto:john.j.light at intel.com> > Date : 2015-04-15 04:57 (GMT+09:00) Title : Re: [dev] glib Please remove it, but don't underestimate how much work it will be. The threading architecture of CA was written assuming profligate use of independent threads, so extricating IoTivity from glib's clutches will require much restructuring. John -----Original Message----- From: [email protected] <mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Rees, Kevron Sent: Tuesday, April 14, 2015 12:51 PM To: Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] glib You should be using glib for mainloop functionality as well (avoids having to use threads at all), but it should be pluggable (able to be replaced with Qt or other mainloops systems as desired). On Tue, Apr 14, 2015 at 11:45 AM, Lankswert, Patrick wrote: > To all, > > The introduction of glib has complicated the stack in a number of ways > from licensing to OS support and beyond. > > In the future, do not draw in additional libraries into Iotivity > without vetting it in this forum. > > I plan to remove the glib dependency from iotivity for several reasons: > 1) IANAL, but the license has viral requirements including the fact > that a dynamically linked LGPL library must be replaceable which is a > problem for RTOSes and linux-based devices TVs and Access Points. > 2) Glib support on iOS (not directly supported), OSX and Windows > (requires > MSYS) is problematic > 3) It is my understanding that we are only using glib for threads and mutex. > This is a lot to pull into iotivity for only two features. > > Before I make this official, I would like to understand any reason > that glib should be kept. Are we using glib for anything other than > threads and mutexes? > > Pat > > Patrick Lankswert > > Intel Corporation > Platform Engineering Group (PEG) / Communications and Devices Group > (CDG) Engineering Manager Louisville, KY, USA > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at > lists.iotivity.org> > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=d083a0c0528fae52303657d 9d21d25cbe9bb1d4a6c32c9a2032aa89e99be1a3e88d6974bd2f79a3cb3b9c254041823979dd 130b31b023ef15296970253332b3707805447a154a46fcf878f9a26ce15a0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150416/ea6666e6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150416/ea6666e6/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150416/ea6666e6/attachment.p7s>
