What I was trying to say was, if we keep the thread handles abstract, we
can switch from pthreads to stdc++ threads without impacting the plugins.
On Tue, Mar 5, 2019 at 5:02 PM Leif Hedstrom wrote:
>
>
> > On Mar 5, 2019, at 2:24 PM, Walt Karas
> wrote:
> >
> > Would we ever want to switch ove
> On Mar 5, 2019, at 2:24 PM, Walt Karas
> wrote:
>
> Would we ever want to switch over to using libstdc++ threads?
I’m likely ok with that, but we have to figure out the story with retaining C
APIs. I.e. this is a big decision to make, making ts/ts.h requiring C++ to
compile.
I’m not *o
Would we ever want to switch over to using libstdc++ threads?
On Tue, Mar 5, 2019 at 3:12 PM Leif Hedstrom wrote:
> I still think it might be time to investigate if eliminating this
> abstraction is better. Like I said, we only support posix threads anyways
> so this abstraction is just extra ov
I still think it might be time to investigate if eliminating this abstraction
is better. Like I said, we only support posix threads anyways so this
abstraction is just extra overhead I assume ?
— Leif
> On Mar 4, 2019, at 09:57, Fei Deng wrote:
>
> I don't like setting cancel state and type
Thanks Leif,
I'd like to understand a bit more before introducing another variable. The
thing that puzzles me the most is why the system objects are behaving
erratically when I am not modifying them or holding on to them..
On Mon, Mar 4, 2019 at 7:11 PM Leif Hedstrom wrote:
> Before going down t
