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. > 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. > 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. > 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. > * 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. > 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. 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). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: This is a digitally signed message part. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150219/2c13531b/attachment.sig>
