Here! Here! Specifically, thread creation near the bottom of the stack is a prime reason there are *20* files duplicated with '_singlethread'. This makes adding features like IPv6 much harder.
John Light Intel OTC OIC Development -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Jon A. Cruz Sent: Monday, April 27, 2015 11:03 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] GLib removal and thread-pool implementation- Additionally, pulling out thread creation from the lower levels and bringing it up higher can increase the responsiveness and versatility of the code. Refactoring the code to no longer create new threads at the lowest levels of the stack, but instead at the higher levels, also allows the removal of a lot of duplicated code. One of the problems from having such duplication is that we do have bugs that are fixed in one copy, but not the other. This problem is occurring in the code now, and will only get worse as time goes on unless the duplication is eliminated. (Sometimes referenced as the rogue tile bug pattern) Moving the thread ownership upward in the stack is actually required to achieve some higher levels of efficiency, and critical for testing. When I've worked up such stacks in the past I was able to create apps that would host tens of thousands of simulated clients simultaneously. In doing so, it became quite easy to exercise the code and measure the points where code cleanup was needed to enable better communication. On 04/27/2015 07:17 AM, Light, John J wrote:> 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.channa at 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.or >> g> https://lists.iotivity.org/mailman/listinfo/iotivity-dev >> _______________________________________________ >> iotivity-dev mailing list >> iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.or >> g> 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] > > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
