[dev] GLib removal and thread-pool implementation-

ev at lists.iotivity.org; ashok.channa at samsung.com Cc: Light, John J; Lankswert, Patrick; Keane, Erich Subject: Re: [dev] GLib removal and thread-pool implementation- On Monday 27 April 2015 10:50:23 ASHOKBABU CHANNA wrote: > By just eliminating the threads we might be simplifying the code but > it

[dev] GLib removal and thread-pool implementation-

On Tuesday 28 April 2015 07:33:39 Light, John J wrote: > Thank you, Thiago, for pointing that out. > > I will add that many robust, well-written C/C++ programs don't set > O_NONBLOCK yet never block, through careful use of select. That is true, though I still advise using O_NONBLOCK. The one cas

[dev] GLib removal and thread-pool implementation-

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504281122569_04A24XEV.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] GLib removal and thread-pool implementation-

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504281010213_QKNMBDIF.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] GLib removal and thread-pool implementation-

On Tuesday 28 April 2015 01:11:00 ASHOKBABU CHANNA wrote: > Unix I/O is asynchronous by nature or can be made so by setting the > O_NONBLOCK flag. > It is possible only with IP stacks but may not be with other connectivity?s > such as BLE and BT and future transports. I would argue that such an A

[dev] GLib removal and thread-pool implementation-

bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] 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

[dev] GLib removal and thread-pool implementation-

On Monday 27 April 2015 10:50:23 ASHOKBABU CHANNA wrote: > 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. That's actually incorrect. It's what a lot of

[dev] GLib removal and thread-pool implementation-

t; Ashok > > --- Original Message --- > > Sender : Keane, Erich > > Date : Apr 25, 2015 06:29 (GMT+09:00) > > Title : Re: [dev] GLib removal and thread-pool implementation- > > > > Hi Pat/all: > > I've put together review 832: >

[dev] GLib removal and thread-pool implementation-

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

[dev] GLib removal and thread-pool implementation-

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

[dev] GLib removal and thread-pool implementation-

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504271950735_QKNMBDIF.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] GLib removal and thread-pool implementation-

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504271938344_QKNMBDIF.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] GLib removal and thread-pool implementation-

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504271004574_93BIV0UV.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] GLib removal and thread-pool implementation-

an think of involve a lot more code. > > :( > > Pat > > > -Original Message- > > From: Keane, Erich > > Sent: Friday, April 24, 2015 1:35 PM > > To: Lankswert, Patrick > > Cc: iotivity-dev at lists.iotivity.org; Macieira, Thiago > > Subjec

[dev] GLib removal and thread-pool implementation-

ginal Message- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > 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 > Subject: Re: [dev] GLib removal an

[dev] GLib removal and thread-pool implementation-

re code. > > :( > > Pat > > > -Original Message- > > From: Keane, Erich > > Sent: Friday, April 24, 2015 1:35 PM > > To: Lankswert, Patrick > > Cc: iotivity-dev at lists.iotivity.org; Macieira, Thiago > > Subject: Re: [dev] GLib removal and threa

[dev] GLib removal and thread-pool implementation-

t: Friday, April 24, 2015 1:35 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org; Macieira, Thiago > Subject: Re: [dev] GLib removal and thread-pool implementation- > > The current use case doesn't actually need an explicit "Join". The > i

[dev] GLib removal and thread-pool implementation-

dev- > > bounces at lists.iotivity.org] On Behalf Of Keane, Erich > > Sent: Friday, April 24, 2015 12:38 PM > > To: Macieira, Thiago > > Cc: iotivity-dev at lists.iotivity.org > > Subject: Re: [dev] GLib removal and thread-pool implementation- > > > > On

[dev] GLib removal and thread-pool implementation-

ounces at lists.iotivity.org [mailto:iotivity-dev- > 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 > Subject: Re: [dev] GLib removal and thread-pool implementation- > > Comme

[dev] GLib removal and thread-pool implementation-

; From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Keane, Erich > Sent: Friday, April 24, 2015 12:38 PM > To: Macieira, Thiago > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] GLib removal and thread-pool im

[dev] GLib removal and thread-pool implementation-

On Fri, 2015-04-24 at 00:02 -0700, Thiago Macieira wrote: > On Thursday 23 April 2015 21:18:11 Keane, Erich wrote: > > 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_

[dev] GLib removal and thread-pool implementation-

- From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Keane, Erich Sent: Thursday, April 23, 2015 2:18 PM To: iotivity-dev at lists.iotivity.org Subject: [dev] GLib removal and thread-pool implementation- Hi all- As many know, I've

[dev] GLib removal and thread-pool implementation-

On Thursday 23 April 2015 21:18:11 Keane, Erich wrote: > 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

[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 detac

[dev] glib

Oleg, Thanks for checking. Pat > -Original Message- > From: Oliver Hahm [mailto:oliver.hahm at inria.fr] > Sent: Friday, April 17, 2015 2:36 AM > To: Lankswert, Patrick > Cc: Rees, Kevron M; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] glib > >

[dev] glib

Hi Pat! > Did you externalize the wrappers that you used for RIOT? Are they reusable? I don't think so, they are pretty much tied and optimized for RIOT's threading model. Cheers, Oleg -- Microsoft Research-Inria Joint Centre B?timent Alan Turing 1 rue Honor? d'Estienne d'Orves Campus de l'?col

[dev] glib

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504171044497_XOK0LK7C.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] glib

: 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

[dev] glib

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504162008532_YKENUIXH.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] glib

anks, Joey -Original Message- From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Jon A. Cruz Sent: Wednesday, April 15, 2015 5:55 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] glib

[dev] glib

> -Original Message- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Wednesday, April 15, 2015 2:29 PM > To: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] glib &g

[dev] glib

> -Original Message- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Wednesday, April 15, 2015 2:30 PM > To: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] glib &g

[dev] glib

65k is still a pretty huge library, that?s larger than our current CSDK stack? From: Othman, Ossama [mailto:ossama.oth...@intel.com] Sent: Wednesday, April 15, 2015 11:06 AM To: Keane, Erich Cc: Light, John J; Lankswert, Patrick; iotivity-dev at lists.iotivity.org Subject: Re: [dev] glib On Wed

[dev] glib

extensive. -Erich -Original Message- From: Light, John J Sent: Wednesday, April 15, 2015 10:09 AM To: Lankswert, Patrick; Keane, Erich Cc: iotivity-dev at lists.iotivity.org; myeong.jeong at samsung.com Subject: RE: [dev] glib Pat, Are you saying there is no hope of ever eliminating the bifu

[dev] glib

, 2015 10:03 AM To: Keane, Erich Cc: iotivity-dev at lists.iotivity.org; Light, John J; myeong.jeong at samsung.com Subject: RE: [dev] glib Erich, Of course. At least one (probably more) thread will be needed and thread protection (mutex) will be required. As we look for ways to reduce threading th

[dev] glib

015 12:55 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org; Light, John J; myeong.jeong at > samsung.com > Subject: Re: [dev] glib > > I definitely agree that we should attempt to remove as many threads as > possible from the csdk/connectivity stack. Ho

[dev] glib

> > From: Light, John J > Sent: Wednesday, April 15, 2015 12:48 PM > To: Lankswert, Patrick; myeong.jeong at samsung.com; > iotivity-dev at lists.iotivity.org > Subject: RE: [dev] glib > > > > > Pat, > > Thank you for expanding on the issue. I also did

[dev] glib

; iotivity-dev at lists.iotivity.org Subject: RE: [dev] glib Pat, Thank you for expanding on the issue. I also didn't mention the "latency vs. throughput" contention that threads contribute to. I'm sure you get these other issues, but I will remind you anyway. "Threadi

[dev] glib

sung.com<mailto:myeong.jeong at samsung.com>; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: [dev] glib All this talk about threads is predicated on the assumption that threads are needed at all. This assumption has bifurcated the connectivi

[dev] glib

system and IO interface support it the same way. That is, I may not be able to listen to a Bluetooth connection using select(). Pat From: Light, John J Sent: Wednesday, April 15, 2015 11:49 AM To: Lankswert, Patrick; myeong.jeong at samsung.com; iotivity-dev at lists.iotivity.org Subject: RE:

[dev] glib

, Patrick Sent: Wednesday, April 15, 2015 5:40 AM To: myeong.jeong at samsung.com; iotivity-dev at lists.iotivity.org Subject: Re: [dev] glib MJ, Answers are inline. From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? Sent: Wednesday,

[dev] glib

r our future. > > John > > -Original Message- > From: Lankswert, Patrick > Sent: Wednesday, April 15, 2015 10:03 AM > To: Keane, Erich > Cc: iotivity-dev at lists.iotivity.org; Light, John J; myeong.jeong at > samsung.com > Subject: RE: [dev] glib > >

[dev] glib

On Wed, Apr 15, 2015 at 12:42 PM, Thiago Macieira wrote: > On Wednesday 15 April 2015 11:09:36 Othman, Ossama wrote: > > On Wed, Apr 15, 2015 at 11:06 AM, Keane, Erich > > > > wrote: > > > 65k is still a pretty huge library, that?s larger than our current > CSDK > > > > > > stack? > > > > It's

[dev] glib

PM > > To: iotivity-dev at lists.iotivity.org > > Subject: Re: [dev] glib > > > > On Wednesday 15 April 2015 16:48:18 Light, John J wrote: > > > A well-constructed select loop can include polling (if that is needed) > > > or external events (if that i

[dev] glib

On Wednesday 15 April 2015 11:09:36 Othman, Ossama wrote: > On Wed, Apr 15, 2015 at 11:06 AM, Keane, Erich > > wrote: > > 65k is still a pretty huge library, that?s larger than our current CSDK > > > > stack? > > It's still far better than the 1+ MB glib library. :) Yeah, but if you replace w

[dev] glib

o: Lankswert, Patrick > Cc: Rees, Kevron M; iotivity-dev at lists.iotivity.org > Subject: Re: [dev] glib > > Hi! > > > Are you aware of well-supported glib implementations that is available > > for iOS, Win32, WinRT or RTOSes like Contiki, uCOS, etc. > > I seriousl

[dev] glib

MJ, Answers are inline. From: iotivity-dev-boun...@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 Subject: Re: [dev] glib Hi, everyone. I'd like to say on the cu

[dev] glib

On Wed, Apr 15, 2015 at 11:28 AM, Thiago Macieira wrote: > On Wednesday 15 April 2015 16:30:21 Lankswert, Patrick wrote: >> For example, It would be nice if we could use select() or epoll() to wait on >> all stack events (IO or mutex). Unfortunately not all operating system and >> IO interface sup

[dev] glib

On Wednesday 15 April 2015 16:48:18 Light, John J wrote: > A well-constructed select loop can include polling (if that is needed) or > external events (if that is needed). I've done both, and they work fine. > John No polling, please. If you wake up, you had better have something to do. -- Thiag

[dev] glib

On Wednesday 15 April 2015 16:30:21 Lankswert, Patrick wrote: > For example, It would be nice if we could use select() or epoll() to wait on > all stack events (IO or mutex). Unfortunately not all operating system and > IO interface support it the same way. That is, I may not be able to listen > to

[dev] glib

An HTML attachment was scrubbed... URL: -- next part -- A non-text attachment was scrubbed... Name: 201504152023793_XOK0LK7C.gif Type: image/gif Size: 13168 bytes Desc: not avai

[dev] glib

On Wed, Apr 15, 2015 at 11:06 AM, Keane, Erich wrote: > 65k is still a pretty huge library, that?s larger than our current CSDK > stack? > It's still far better than the 1+ MB glib library. :) -- next part -- An HTML attachment was scrubbed... URL:

[dev] glib

On Wed, Apr 15, 2015 at 10:40 AM, Keane, Erich wrote: > Since there weren't really any good reasons that anyone mentioned to KEEP > Glib, I'm going to start the effort to write a lightweight multi-platform > version for it. The CA Layer does a great job abstracting the mutex/thread > usage out,

[dev] glib

Hi! > Are you aware of well-supported glib implementations that is available for > iOS, Win32, WinRT or RTOSes like Contiki, uCOS, etc. I seriously doubt that you'll find a real IoT RTOS that deals with glib - it's just too fat. > What is more work, porting glib to the next OS/RTOS or implement

[dev] glib

On Wednesday 15 April 2015 12:41:49 Lankswert, Patrick wrote: > Thanks for joining the conversation and sharing your experience. > > Did you externalize the wrappers that you used for RIOT? Are they reusable? Adding to that: we don't need a POSIX-compliant wrapper, we probably only need a small

[dev] glib

-dev at lists.iotivity.org; Rees, Kevron M > > Subject: Re: [dev] glib > > > > On Tue, 2015-04-14 at 21:01 +, Lankswert, Patrick wrote: > > > Kevron, > > > > > > > -Original Message- > > > > From: Rees, Kevron [mailto:kevron.m.rees

[dev] glib

Erich, Because I could not resist... > -Original Message- > From: Keane, Erich > Sent: Tuesday, April 14, 2015 5:06 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org; Rees, Kevron M > Subject: Re: [dev] glib > > On Tue, 2015-04-14 at 21:01 +

[dev] glib

gt; > > What is more work, porting glib to the next OS/RTOS or implementing a > > > thread and mutex wrapper for each OS? > > > > > > Pat > > > > > >> -Original Message- > > >> From: Rees, Kevron [mailto:kevron.m.rees at int

[dev] glib

, Ossama; Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: RE: [dev] glib Just adding a quick note.. Hi Pat, On Tue, Apr 14, 2015 at 1:40 PM, Lankswert, Patrick mailto:patrick.lankswert at intel.com> > wrote: Ossama, I am not sure that your case justifies making

[dev] glib

Kevron, > -Original Message- > From: Rees, Kevron [mailto:kevron.m.rees at intel.com] > Sent: Tuesday, April 14, 2015 4:46 PM > To: Lankswert, Patrick > Cc: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] glib > > I wasn't aware that glib was bein

[dev] glib

Just adding a quick note.. Hi Pat, On Tue, Apr 14, 2015 at 1:40 PM, Lankswert, Patrick mailto:patrick.lankswert at intel.com>> wrote: Ossama, I am not sure that your case justifies making glib a requirement for the entire stack on multi-threaded systems. I wasn't trying to justify making glib a

[dev] glib

The copy of DSL I have on an old server doesn't :) On Tue, 2015-04-14 at 13:49 -0700, Othman, Ossama wrote: > Hi Pat, > > On Tue, Apr 14, 2015 at 1:40 PM, Lankswert, Patrick > wrote: > Ossama, > > > > I am not sure that your case justifies making glib

[dev] glib

: Tuesday, April 14, 2015 3:54 PM To: Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] glib Hi Pat, On Tue, Apr 14, 2015 at 11:45 AM, Lankswert, Patrick mailto:patrick.lankswert at intel.com> > wrote: The introduction of glib has complicated the stack in a num

[dev] glib

ts.iotivity.org > Subject: Re: [dev] glib > > Also, I'm not sure "1" is actually a problem. This is not GPL 3 that > requires the > device to be hackable where you could replace a lgpl library. Literally > hundreds of devices ship with LGPL code. > > On Tue, Ap

[dev] glib

tivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@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 Subject: Re: [dev] glib You should be using glib for mainloop functionality as we

[dev] glib

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) IA

[dev] glib

On Tuesday 14 April 2015 18:45:30 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. > >

[dev] glib

On 04/14/2015 02:01 PM, Lankswert, Patrick wrote: > Kevron, > >> > -Original Message- >> > From: Rees, Kevron [mailto:kevron.m.rees at intel.com] >> > Sent: Tuesday, April 14, 2015 4:46 PM >> > To: Lankswert, Patrick >> > Cc: iotivity-dev

[dev] glib

On Tue, Apr 14, 2015 at 2:04 PM, Lankswert, Patrick < patrick.lankswert at intel.com> wrote: > Ossama, > > > > We are all good here also. The data point is good. Even if we remove the > requirement from the core stack, we should be able to continue to support > your scenarios as currently defined

[dev] glib

On Tue, Apr 14, 2015 at 1:52 PM, Morrow, Joseph L wrote: > Just adding a quick note.. > > Hi Pat, > > > > On Tue, Apr 14, 2015 at 1:40 PM, Lankswert, Patrick < > patrick.lankswert at intel.com> wrote: > > Ossama, > > > > I am not sure that your case justifies making glib a requirement for the

[dev] glib

Hi Pat, On Tue, Apr 14, 2015 at 1:40 PM, Lankswert, Patrick < patrick.lankswert at intel.com> wrote: > Ossama, > > > > I am not sure that your case justifies making glib a requirement for the > entire stack on multi-threaded systems. > I wasn't trying to justify making glib a requirement, and wa

[dev] glib

e- >> From: Rees, Kevron [mailto:kevron.m.rees at intel.com] >> Sent: Tuesday, April 14, 2015 3:56 PM >> To: Lankswert, Patrick >> Cc: iotivity-dev at lists.iotivity.org >> Subject: Re: [dev] glib >> >> Also, I'm not sure "1" is actual

[dev] glib

Also, I'm not sure "1" is actually a problem. This is not GPL 3 that requires the device to be hackable where you could replace a lgpl library. Literally hundreds of devices ship with LGPL code. On Tue, Apr 14, 2015 at 12:51 PM, Rees, Kevron wrote: > You should be using glib for mainloop funct

[dev] glib

Hi Pat, On Tue, Apr 14, 2015 at 11:45 AM, Lankswert, Patrick < patrick.lankswert at intel.com> wrote: > > 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 >

[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 h