FWIW, I'm VERY much in agreement that this needs to be done before 1.0. I'd prefer actually deleting the old ones if at all possible (though I know how much headache that would be...), but at least make all our examples do it.
There is a little additional work that would be done in the C++ layer to deal with this, as a lot of the C++ threading decisions were to get around the global-variable-ness of the C stack. Finally, I'd be completely up for working on this, it seems like a fun project, and I have a pretty good knowledge of most of the stack. On Thu, 2015-02-19 at 16:37 +0000, Lankswert, Patrick wrote: > Thiago, > > > -----Original Message----- > > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > > Sent: Thursday, February 19, 2015 11:22 AM > > To: iotivity-dev at lists.iotivity.org > > Subject: Re: [dev] Ripping out the threads > > > > On Thursday 19 February 2015 07:13:45 Lankswert, Patrick wrote: > > > > option. A simple plan that comes to mind is as follows: > > > > > > > > 1) create an ITVTContext struct > > > > 2) move all global variables to the context > > > > 3) begin duplicating the current API with calls that take the > > > > context as a > > > > > > > > parameter, while making the current API use a global, shared > > > > > > ITVTContext > > > > > > > 4) deprecate and later remove the old non-context API. > > > > > > > > Note on 3: this also gives us the opportunity to apply our naming > > > > change without breaking existing codebase. > > > > > > > > Note on 4: we can opt to keep the context-less API as a convenience. > > > > > > > > Of course, no plan survives contact with the enemy, so I'm pretty > > > > sure it won't be as simple as I suggested. > > > > > > Thiago, > > > > > Can I assume that you are planning to do your design based on the > > > connectivity abstraction branch? > > > > After it lands, with the changes from everyone implemented. Doing > > otherwise would mean a lot of re-work due when it finally does land. > > I agree. > > > > Regarding the context; are you thinking of a concrete context struct > > > or handle to a context with a factory pattern aka "ITVTContext* > > > createContext();"? > > > > Yes, just like SSL_CTX from OpenSSL or DBusConnection from libdbus-1. It > > should be an opaque pointer that is created and destroyed by the library > > only. > > > > We can discuss whether we should adopt refcounting or whether the user > > needs to know when to drop the reference. > > I agree. > > > > Regarding keeping the context-API as convenience; are you suggesting > > > dual stacks or a context-less API that is a fa?ade of the context API? > > > > The context-less API a fa?ade of the context one, by simply using a > shared, > > global context that is kept inside the library. > > I was hoping that you would say that. > > > > What I like about the context: > > > * It captures the stack space cost concisely versus a bunch of > > > scattered globals > > > > Heap space, since the struct will be opaque and will be allocated by > malloc() > > by the library. > > It does not have to use malloc(). For example, two factories: > * general: uses malloc() as you would expect > * embedded: returns unused context from fixed pool where the pool size could > be one and returns NULL when exceeded. > > > > * May allow multiple instances of the stack to operate in the same > > > space > > > * It should improve re-entrancy > > > * Even in C, this is an OO approach > > > > Right, text-book OO-in-C approach. > > > > Preferred. > > > > What I am concerned about the context [to be reviewed after you > > > initial analysis] > > > * Cost versus benefit of the effort. Is something more important to do? > > > > You or others may disagree with me, but I feel this is quite important to > get > > right before the 1.0 release, if we want people to use the new API and not > > the old, thread-unsafe one. > > > > Could not say yet... I do not know the cost. > > > I also feel this is important enough to do, even for a substantially > higher cost. > > > > > * Is it solving a real problem? > > > > I believe so, I wouldn't be proposing otherwise. > > > > And as a maintainer in another project that loves to wrap libraries and > > provide a nicer C++ front-end API, I can tell you we absolutely hate > shared > > global states. OpenGL is a contender in that list, though at the very > least you > > can set and unset the global context. > > > > My current pet-peeve are Unix signals and how you're forced to use them > > when launching processes with fork(). It's very hard for libraries to get > them > > right. A good example of this is what happens if you use gspawn (from > glib) > > after QProcess: glib's implementation removes Qt's SIGCHLD handler, so > > QProcess stops working from that point on. > > > > > * How will the design change impact RTOS or embedded environments? > > > > Provided those OS have malloc(), the effect should be minimal: memory > > consumption should be roughly the same (TBV), with a slight increase due > to > > malloc() overhead. Runtime performance may suffer a slight drop due to > > register pressure on platforms with few general-purpose registers (namely, > > i386). > > There are many environments where malloc() is discouraged or verboten since > heaps can be non-deterministic when small (<2kb) as a result of heap > fragmentation. As long as I have a mandate to support the small devices, I > need contributors designs to address these issues. At this point, I do not > see a problem here. > > Pat > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
