My underlying point about context pointers is that they are orthogonal
regardless of the presence or lack of concurrency, and for the most part
also of any concurrency model you'd like to use. 

It's just a strategy for moving away global state. That's not the only
way that it could be written, of course, but it's in line with parts of
the standard library (such as stdio.h's high-level I/O fuctions (e.g.
fopen()) and easy both to understand and use (although it does add a
resource management component).

To Erik's point about priority, yeah, folks will have to decide that,
but I can't think of much that a /lack/ of context will make easier. If
anything, the longer it's not present the more there will be to unravel
and the more dependent upon shared state the library could become. So
I'd say sooner rather than later... 

Felix: There are pretty good arguments on both sides of that fence (for
instance, requiring the application to hold the mutex locks the whole
call into the API, wheras internal locks require no explicit interaction
from the user and can be finely tuned). Another approach is to register
locking functions into the context itself (there's the cost of another
derefence and pointer, etc.). It feels to me like that's a big design
issue that will require a lot of discussion.

Just my two bits,

-Jesse

To Erik's point about 

On Tue, 2015-02-17 at 23:08 +0000, Felix Freimann wrote:
> Hi all
> 
> Quick question; Assume we do create a thread-save OIC library (right now in 
> discussion) using some form of lock mechanism. Would the OIC callbacks first 
> obtain the locks before executing the callback function or would the callback 
> function be called without holding a lock?
> 
> Ta
> 
> Felix Freimann
> 
> "The standard you walk past is the standard you accept."
> 
> MediaTek USA
> 
> Email: felix.freimann at mediatek.com
> Phone: +1 408 526 1899, x88108
> Fax: +1 408 526 1991
> 
> 
> -----Original Message-----
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-bounces 
> at lists.iotivity.org] On Behalf Of Keane, Erich
> Sent: Tuesday, February 17, 2015 3:01 PM
> To: Othman, Ossama
> Cc: iotivity-dev at lists.iotivity.org
> Subject: Re: [dev] Ripping out the threads
> 
> I'll state for the record that I am all for a change like this.  My concern 
> is the effort related to it would be massive and likely result in delaying a 
> ton of features that many find important.  
> 
> My point basically is that "I like this, but it needs to go through 
> prioritization".
> 
> On Tue, 2015-02-17 at 14:58 -0800, Othman, Ossama wrote:
> > On Tue, Feb 17, 2015 at 1:44 PM, Williamson, Jesse F 
> > <jesse.f.williamson at intel.com> wrote:
> >         For C anyway, why not just provide contexts?
> >         
> >         OCCtx *ctx = OCCtxInit(config);
> >         
> >         if(NULL == ctx)
> >          return error();
> >         
> >         // ...
> >         OCProcess(ctx);
> >         // ...
> >         
> >         OCCtxDestroy(ctx);
> >         
> >         ...and so on. This unfortunately is a breaking change, but it
> >         gives us a
> >         way to eliminate shared global state (i.e. global variables)
> >         and can be
> >         used whether there are coroutines, multiple contexts, threads,
> >         or not.
> > 
> > 
> >  Agreed!  It's better to make this sort of change now, since the API 
> > is still quite young.
> > 
> > 
> > -Ossama
> > _______________________________________________
> > iotivity-dev mailing list
> > iotivity-dev at lists.iotivity.org
> > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
> 
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
> ************* Email Confidentiality Notice ********************
> The information contained in this e-mail message (including any 
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be 
> conveyed only to the designated recipient(s). Any use, dissemination, 
> distribution, printing, retaining or copying of this e-mail (including its 
> attachments) by unintended recipient(s) is strictly prohibited and may 
> be unlawful. If you are not an intended recipient of this e-mail, or believe 
> that you have received this e-mail in error, please notify the sender 
> immediately (by replying to this e-mail), delete any and all copies of 
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
> 
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev

Reply via email to