Hi Jesse Yep, I agree that this is a big design issue and we need to think carefully we want this to work.
Potentially, it is possible that code outside of the OIC library also contains some form of lock for whatever reason. This means there could be a lock inside of the OIC library and one outside (over which OIC has no control). Hence, it is easily possible that depending on call sequence these two locks are grabbed in a different sequence which would lead to task lock-up's. Conversely, if we require the user to explicitly lock the OIC library before making an OIC API call then we simply place the burden onto the user. All the best 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:[email protected]] On Behalf Of Williamson, Jesse F Sent: Tuesday, February 17, 2015 3:23 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Ripping out the threads 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 _______________________________________________ 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!
