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:
> > > >
> > >
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: [de
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: [de
On Thursday 19 February 2015 08:37:05 Lankswert, Patrick wrote:
> 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 co
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
> >
>
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. L
> -Original Message-
> From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-
> bounces at lists.iotivity.org] On Behalf Of Thiago Macieira
> Sent: Wednesday, February 18, 2015 2:11 AM
> To: iotivity-dev at lists.iotivity.org
> Subject: Re: [dev] Rippi
-dev-bounces at lists.iotivity.org
[mailto:iotivity-dev-boun...@lists.iotivity.org] 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
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
>
>
On Tuesday 17 February 2015 23:40:43 Felix Freimann wrote:
> 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,
ty.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 mas
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
y-dev at lists.iotivity.org
> Subject: Re: [dev] Ripping out the threads
>
> A little bit of history regarding the C stack. It was implemented first and
> wasn't originally intended to be thread-safe. The initial thought was that
> that would allow it to run efficiently and ha
In the current state of things (assuming the C stack isn't made
re-entrant), calling the processing function at the same time as another
thread would cause some nasty memory issues.
On Tue, 2015-02-17 at 13:07 -0800, Thiago Macieira wrote:
> On Tuesday 17 February 2015 13:04:00 Keane, Erich wrote
] On Behalf Of Hudson, Douglas
Sent: Tuesday, February 17, 2015 3:54 PM
To: Macieira, Thiago; iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Ripping out the threads
A little bit of history regarding the C stack. It was implemented first and
wasn't originally intended to be thread-safe.
On Tue, 2015-02-17 at 12:27 -0800, Thiago Macieira wrote:
> On Tuesday 17 February 2015 11:35:33 Keane, Erich wrote:
> > > > Removing the threads spawned upon message retrieval wouldn't be that
> > > > big
> > > > of a deal, however it would cause a few problems. Note that each of
> > > > these is
ubject: Re: [dev] Ripping out the threads
On Tuesday 17 February 2015 11:35:33 Keane, Erich wrote:
> > > Removing the threads spawned upon message retrieval wouldn't be
> > > that big of a deal, however it would cause a few problems. Note
> > > that each of these is c
On Tue, 2015-02-17 at 11:27 -0800, Thiago Macieira wrote:
> On Tuesday 17 February 2015 11:13:42 Keane, Erich wrote:
> > Making the C library thread-safe is giong to be quite an undertaking,
> > potentially requiring a ton of re-design work and changing a good number
> > of the APIs (particularly i
Making the C library thread-safe is giong to be quite an undertaking,
potentially requiring a ton of re-design work and changing a good number
of the APIs (particularly if reentrance is something we want).
As far as having C++ stop spawning threads, they are quite required
unfortunately. Unless w
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. T
On 02/17/2015 12:27 PM, Thiago Macieira wrote:
> On Tuesday 17 February 2015 11:35:33 Keane, Erich wrote:
Removing the threads spawned upon message retrieval wouldn't be that
big
of a deal, however it would cause a few problems. Note that each of
these is called in the C-cont
On Tuesday 17 February 2015 13:04:00 Keane, Erich wrote:
> > Why would there be performance problems by running multiple threads that
> > handle sockets?
>
> Not that they have their own sockets, but the issue would be if each is
> expecting to run their own thread for the message pump (which nee
On Tuesday 17 February 2015 12:54:04 Hudson, Douglas wrote:
> A little bit of history regarding the C stack. It was implemented first and
> wasn't originally intended to be thread-safe. The initial thought was that
> that would allow it to run efficiently and have less of a footprint on a
> bare-
On Tuesday 17 February 2015 11:35:33 Keane, Erich wrote:
> > > Removing the threads spawned upon message retrieval wouldn't be that
> > > big
> > > of a deal, however it would cause a few problems. Note that each of
> > > these is called in the C-context, so it would result in user-code
> > > free
On Tuesday 17 February 2015 11:13:42 Keane, Erich wrote:
> Making the C library thread-safe is giong to be quite an undertaking,
> potentially requiring a ton of re-design work and changing a good number
> of the APIs (particularly if reentrance is something we want).
I know. But I feel it's quite
Hello all
Short story:
Another team inside Intel was trying the IoTivity library and one of the
feedback items they gave to me was that the library is "threadful but not
thread-safe". I did a little investigation and asked some people some
questions and it seems they are right. That seems to m
26 matches
Mail list logo
