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 1:30 AM > To: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Ripping out the threads > > On Wednesday 18 February 2015 08:15:40 Lankswert, Patrick wrote: > > Ok, we all agree that threaded, re-entrant code is good. Deadlocks are bad. > > Clear locking order is good.... > > > > Can we get to some code? Can you provide concrete examples of these > > issues and a suggestion for something better. Let's get our hands dirty. > > Hi Pat > > This part of the discussion was theoretical. I don't have any examples of code > that deadlocks. > > My goal is to start hacking away at the C SDK and start providing a reentrant > 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, That is what I would prefer to talk about. Concrete, incremental and actionable. The reason that I prefer the concrete is that, on many projects, I have seen a lot of "this should have been done differently" before developers (including myself) really understand how something is working. In my mind, this can lead to two poor mindsets where "Perfect is the enemy of good" and "Intolerance of the least-worst option". Can I assume that you are planning to do your design based on the connectivity abstraction branch? Regarding the context; are you thinking of a concrete context struct or handle to a context with a factory pattern aka "ITVTContext* createContext();"? 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? What I like about the context: * It captures the stack space cost concisely versus a bunch of scattered globals * 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 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? * Is it solving a real problem? * How will the design change impact RTOS or embedded environments? 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/dd7e08c4/attachment.p7s>
