Ashok, I understand your concerns, and I won't accept a design that results in blocking I/O calls. All the recvfrom calls are behind a select, and the select (in my proposed simplification) is run by its own thread. So it is impossible for a recvfrom to block with my proposed design. There are other places where blocking might happen. For example, all the sends may potentially block in the current design, but that's ok because they are on separate threads. The final thread queue in the send path should be replaced by a select as well, but I am not proposing that. Blocking I/O doesn't result from lack of threads; it results from weak designs. I propose upgrading our designs, which will allow using fewer and less dynamic threads, but only a step at a time. We have the opportunity to reduce the number of sockets and threads, and eliminate an entire thread pool. This will put us on the path to eliminating glib. BTW, I am not advocating a single thread model. I am advocating using far fewer threads, with the option of adding them back into rich devices as needed. John
From: ASHOKBABU CHANNA [mailto:ashok.cha...@samsung.com] Sent: Monday, April 27, 2015 3:50 AM To: Light, John J; Lankswert, Patrick; Keane, Erich; iotivity-dev at lists.iotivity.org Subject: Re: Re: [dev] GLib removal and thread-pool implementation- By just eliminating the threads we might be simplifying the code but it might cause lot of blocking issues. Multi thread concept itself derived to eliminate the blocking of I/O operations. When we are talking about Internet of things having a single thread model at the base stack may not help IoTivity to grow. (For RICH Devices especially) If we have services such as Remote access or multiple connectivity (may be blocking I/O such as BLE,BT) in base layer, all the applications will be waiting for others to finish without having multi-threaded environment. Reducing the number of threads and also usage of mutex is better way than making a single threaded application. Regards, Ashok ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : Apr 25, 2015 02:47 (GMT+09:00) Title : Re: [dev] GLib removal and thread-pool implementation- "Do you believe that we can incrementally improve thread handling?" Emphatically, yes. My comment on the Ethernet/Wifi thread shows a way to simplify this new code by eliminating the thread pool at the bottom in CAReceiveHandler. An entire thread pool! Besides eliminating the thread pool, it simplifies the code, especially with the application of IOT-496, and prepares for easier adoption of IPv6. John -----Original Message----- From: Lankswert, Patrick Sent: Friday, April 24, 2015 10:14 AM To: Light, John J; Keane, Erich; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: GLib removal and thread-pool implementation- John, I generally agree in principle. However, I think that the step function of bring CA online was expensive to the project. I want to avoid another step function. Do you believe that we can incrementally improve thread handling? Pat > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces > at lists.iotivity.org> [mailto:iotivity-dev- > bounces at lists.iotivity.org<mailto:bounces at lists.iotivity.org>] On > Behalf Of Light, John J > Sent: Friday, April 24, 2015 11:16 AM > To: Keane, Erich; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at > lists.iotivity.org> > Subject: Re: [dev] GLib removal and thread-pool implementation- > > Comments? You asked. > > We should be working to eliminate all the thread pools. All of the thread > pools in current master, including the connectivity abstraction, are > unnecessary and have no real affect other than to complicate the code and > create difficult problems. I submit without proof that running IoTivity on two > threads (main process and application callbacks, in addition to application > thread), would provide all the functional and performance advantages we > now generate from all the threads and thread pools we now have. I believe > that, in a rational development environment, all the extra threading should > have to be justified. Instead, I find that I must argue for fewer threads. > > Spending more effort to eliminate threads and less to make them palatable > would have a bigger positive effect on IoTivity. > > John Light > Intel OTC OIC development > > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces > at lists.iotivity.org> [mailto:iotivity-dev- > bounces at lists.iotivity.org<mailto:bounces at lists.iotivity.org>] On > Behalf Of Keane, Erich > Sent: Thursday, April 23, 2015 2:18 PM > To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at > lists.iotivity.org> > Subject: [dev] GLib removal and thread-pool implementation- > > Hi all- > As many know, I've been working to remove glib as a compilation > dependency for non-tizen systems. I've done this in review 747: > https://gerrit.iotivity.org/gerrit/#/c/747 > > My concern is with my threadpool implementation. The implementation in > 747 is merely a dispatcher, starting and detaching a thread when requested. > > After analyzing the code, it seems like this should be sufficient, however a > few comments have been made on the review that disagree. I wanted to > extract that conversation here for further discussion. > > Another alternative that I thought of based on Ashok's feedback is an > unlimited pool-thread system (essentially functionally like the glib > implementation, since the thread_count is greater than requested threads), > where the threads list is stored in an array list, then can be joined at the end. > I'm not sure what that buys us other than blocking until all threads have been > completed, but Ashok's comments seem to believe that it is a necessity. > > So, thoughts/comments? > -Erich > _______________________________________________ > 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 [cid:image001.gif at 01D080BA.40CFFFB0] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=deb3de73a46b1d5505e3644abd2aa1ae53d6a5c6adcaa881a1889aa8efbbee47738ed17e7639ce1f641b1a8c451b073656239170f5eb4b5c326bbdfb2ea96a2fcf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150427/47cf63e3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150427/47cf63e3/attachment.gif>
