MJ, Answers are inline.
From: [email protected] [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 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. 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. 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. 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=d083a0c0528fae52da4c16d 647295d1e6eabc8577b8d8389032aa89e99be1a3e13d69ea60670f66e1fac5bf6c61543587bc 8a6096cfbfc9f02e038c8d853bffbdb9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a 0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150415/67a72f70/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/20150415/67a72f70/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/20150415/67a72f70/attachment.p7s>
