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 -------------- 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/20150219/f5e28240/attachment.p7s>
