You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Walt Karas <wk...@oath.com.INVALID> on 2018/03/16 23:39:20 UTC
continuations in C++ API
Does this seem like a good wrapper class for continuations in the C++ API?
class Continuation
{
public:
Continuation(TSMutex mutexp = TSMutexCreate()) :
_cont(TSContCreate(_generalEventFunc, mutexp))
{
TSContDataSet(_cont, static_cast<void *>(this));
}
TSCont
asTSCont() const
{
return _cont;
}
void
destroy()
{
if (_cont) {
TSContDestroy(_cont);
_cont = nullptr;
}
}
~Continuation()
{
if (_cont) {
TSContDestroy(_cont);
}
}
// No copying.
Continuation(const Continuation &) = delete;
Continuation &operator=(const Continuation &) = delete;
// Moving allowed.
Continuation(Continuation &&that)
{
_cont = that._cont;
that._cont = nullptr;
}
Continuation &
operator=(Continuation &&that)
{
if (&that != this) {
if (_cont) {
TSContDestroy(_cont);
}
_cont = that._cont;
that._cont = nullptr;
}
return *this;
}
explicit operator bool() const { return _cont != nullptr; }
private:
// Distinct continuation behavior is achieved by overriding this
function in a derived continuation type.
//
virtual int _run(TSEvent event, void *edata) = 0;
// This is the event function for all continuations in C++ plugins.
//
static int _generalEventFunc(TSCont cont, TSEvent event, void *edata);
TSCont _cont;
};
Re: continuations in C++ API
Posted by Derek Dagit <de...@oath.com.INVALID>.
> I'm pretty sure TSContDestroy() also destroys any mutex for the
continuation.
Well, sure. But what I was trying to say is that not all Continuations
require a mutex. By default, in the C API they do not have one unless you
explicitly pass one.
This proposes an inconsistent change in that by default, new Continuations
do have a mutex.
I think it is not a C/C++ question, but an API functionality/usability
question.
On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas <wk...@oath.com.invalid>
wrote:
> I'm pretty sure TSContDestroy() also destroys any mutex for the
> continuation. (Per our other discussion, I got exasperated trying to
> make sure of this looking through the code with just vi.)
>
> On Mon, Mar 19, 2018 at 10:23 AM, Derek Dagit <de...@oath.com.invalid>
> wrote:
> > I might be missing the connection to the proposed Continuation
> constructor
> > behavior with regard to the mutex.
> >
> > If there is a good reason to change this behavior, we should consider it.
> > Otherwise it's probably best to keep consistency with the existing API.
> >
> > On Mon, Mar 19, 2018 at 10:16 AM, Walt Karas <wk...@oath.com.invalid>
> > wrote:
> >
> >> The current C interface is bad because resources are not freed in
> >> destructors, and the use of raw void pointers is necessary.
> >>
> >> On Mon, Mar 19, 2018 at 10:09 AM, Derek Dagit <de...@oath.com.invalid>
> >> wrote:
> >> > OK, so I am in favor of consistency with the existing C API, if
> possible
> >> > and only if there is not good reason to break with the way the C API
> is
> >> > doing it.
> >> >
> >> > On Mon, Mar 19, 2018 at 9:58 AM, Walt Karas <wk...@oath.com.invalid>
> >> wrote:
> >> >
> >> >> yes
> >> >>
> >> >>
> >> >> On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit <derekd@oath.com.invalid
> >
> >> >> wrote:
> >> >> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
> >> >> >
> >> >> > Not every continuation requires a mutex. To get behavior similar to
> >> the
> >> >> > current C API we would need to pass a `nullptr` to the constructor,
> >> >> right?
> >> >> >
> >> >> > On Fri, Mar 16, 2018 at 6:39 PM, Walt Karas
> <wk...@oath.com.invalid>
> >> >> wrote:
> >> >> >
> >> >> >> Does this seem like a good wrapper class for continuations in the
> C++
> >> >> API?
> >> >> >>
> >> >> >> class Continuation
> >> >> >> {
> >> >> >> public:
> >> >> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
> >> >> >> _cont(TSContCreate(_generalEventFunc, mutexp))
> >> >> >> {
> >> >> >> TSContDataSet(_cont, static_cast<void *>(this));
> >> >> >> }
> >> >> >>
> >> >> >> TSCont
> >> >> >> asTSCont() const
> >> >> >> {
> >> >> >> return _cont;
> >> >> >> }
> >> >> >>
> >> >> >> void
> >> >> >> destroy()
> >> >> >> {
> >> >> >> if (_cont) {
> >> >> >> TSContDestroy(_cont);
> >> >> >> _cont = nullptr;
> >> >> >> }
> >> >> >> }
> >> >> >>
> >> >> >> ~Continuation()
> >> >> >> {
> >> >> >> if (_cont) {
> >> >> >> TSContDestroy(_cont);
> >> >> >> }
> >> >> >> }
> >> >> >>
> >> >> >> // No copying.
> >> >> >> Continuation(const Continuation &) = delete;
> >> >> >> Continuation &operator=(const Continuation &) = delete;
> >> >> >>
> >> >> >> // Moving allowed.
> >> >> >> Continuation(Continuation &&that)
> >> >> >> {
> >> >> >> _cont = that._cont;
> >> >> >> that._cont = nullptr;
> >> >> >> }
> >> >> >> Continuation &
> >> >> >> operator=(Continuation &&that)
> >> >> >> {
> >> >> >> if (&that != this) {
> >> >> >> if (_cont) {
> >> >> >> TSContDestroy(_cont);
> >> >> >> }
> >> >> >> _cont = that._cont;
> >> >> >> that._cont = nullptr;
> >> >> >> }
> >> >> >> return *this;
> >> >> >> }
> >> >> >>
> >> >> >> explicit operator bool() const { return _cont != nullptr; }
> >> >> >>
> >> >> >> private:
> >> >> >> // Distinct continuation behavior is achieved by overriding this
> >> >> >> function in a derived continuation type.
> >> >> >> //
> >> >> >> virtual int _run(TSEvent event, void *edata) = 0;
> >> >> >>
> >> >> >> // This is the event function for all continuations in C++
> plugins.
> >> >> >> //
> >> >> >> static int _generalEventFunc(TSCont cont, TSEvent event, void
> >> *edata);
> >> >> >>
> >> >> >> TSCont _cont;
> >> >> >> };
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Derek
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Derek
> >>
> >
> >
> >
> > --
> > Derek
>
--
Derek
Re: continuations in C++ API
Posted by Derek Dagit <de...@oath.com.INVALID>.
> Or maybe no default to avoid confusion?
Yeah this sounds fine to me too.
On Mon, Mar 19, 2018 at 4:23 PM, Walt Karas <wk...@oath.com.invalid> wrote:
> Or maybe no default to avoid confusion?
>
> On Mon, Mar 19, 2018 at 4:08 PM, Derek Dagit <de...@oath.com.invalid>
> wrote:
> > I think that would be better, because it's consistent with the current
> API.
> >
> > Sorry if I wasn't clear on that before.
> >
> > On Mon, Mar 19, 2018 at 4:07 PM, Walt Karas <wk...@oath.com.invalid>
> wrote:
> >
> >> So is the upshot that the mutex param to the constructor should
> >> default to nullptr?
> >>
> >> On Mon, Mar 19, 2018 at 4:04 PM, Derek Dagit <de...@oath.com.invalid>
> >> wrote:
> >> > A continuation's Mutex is also used for certain API functions, like
> >> > TSHostLookup:
> >> >
> >> > https://docs.trafficserver.apache.org/en/latest/
> >> developer-guide/api/functions/TSHostLookup.en.html
> >> >
> >> > But you do not always need them.
> >> >
> >> > On Mon, Mar 19, 2018 at 3:48 PM, Alan Carroll <
> >> > solidwallofcode@oath.com.invalid> wrote:
> >> >
> >> >> Yes. I have seen reference count numbers in the high teens for some
> >> >> mutexes.
> >> >>
> >> >> On Mon, Mar 19, 2018 at 3:32 PM, Walt Karas <wkaras@oath.com.invalid
> >
> >> >> wrote:
> >> >>
> >> >> > So it's possible that two different continuations may be sharing a
> >> single
> >> >> > mutex?
> >> >> >
> >> >> >
> >> >> > On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll
> >> >> > <so...@oath.com.invalid> wrote:
> >> >> > > Walt - I think Derek is commenting stylistically, that if no
> Mutex
> >> is
> >> >> the
> >> >> > > default for the C API, then it should be the default for the C++
> as
> >> >> well.
> >> >> > >
> >> >> > > What about a user conversion to TSCont in addition to an explicit
> >> >> method?
> >> >> > > If you could, writing this up as a Sphinx API doc would be cool.
> >> >> > >
> >> >> > > On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <
> >> >> solidwallofcode@oath.com>
> >> >> > > wrote:
> >> >> > >
> >> >> > >> Indirectly. What's stored in the Continuation is a shared
> pointer
> >> to
> >> >> the
> >> >> > >> Mutex. That shared pointer is destructed by TSContDestroy which
> >> may in
> >> >> > turn
> >> >> > >> destruct the Mutex (or not, if there are still references to
> it).
> >> >> > >>
> >> >> > >> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas
> >> <wkaras@oath.com.invalid
> >> >> >
> >> >> > >> wrote:
> >> >> > >>
> >> >> > >>> I'm pretty sure TSContDestroy() also destroys any mutex for the
> >> >> > >>> continuation. (Per our other discussion, I got exasperated
> >> trying to
> >> >> > >>> make sure of this looking through the code with just vi.)
> >> >> > >>>
> >> >> > >>>
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Derek
> >>
> >
> >
> >
> > --
> > Derek
>
--
Derek
Re: continuations in C++ API
Posted by Walt Karas <wk...@oath.com.INVALID>.
Or maybe no default to avoid confusion?
On Mon, Mar 19, 2018 at 4:08 PM, Derek Dagit <de...@oath.com.invalid> wrote:
> I think that would be better, because it's consistent with the current API.
>
> Sorry if I wasn't clear on that before.
>
> On Mon, Mar 19, 2018 at 4:07 PM, Walt Karas <wk...@oath.com.invalid> wrote:
>
>> So is the upshot that the mutex param to the constructor should
>> default to nullptr?
>>
>> On Mon, Mar 19, 2018 at 4:04 PM, Derek Dagit <de...@oath.com.invalid>
>> wrote:
>> > A continuation's Mutex is also used for certain API functions, like
>> > TSHostLookup:
>> >
>> > https://docs.trafficserver.apache.org/en/latest/
>> developer-guide/api/functions/TSHostLookup.en.html
>> >
>> > But you do not always need them.
>> >
>> > On Mon, Mar 19, 2018 at 3:48 PM, Alan Carroll <
>> > solidwallofcode@oath.com.invalid> wrote:
>> >
>> >> Yes. I have seen reference count numbers in the high teens for some
>> >> mutexes.
>> >>
>> >> On Mon, Mar 19, 2018 at 3:32 PM, Walt Karas <wk...@oath.com.invalid>
>> >> wrote:
>> >>
>> >> > So it's possible that two different continuations may be sharing a
>> single
>> >> > mutex?
>> >> >
>> >> >
>> >> > On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll
>> >> > <so...@oath.com.invalid> wrote:
>> >> > > Walt - I think Derek is commenting stylistically, that if no Mutex
>> is
>> >> the
>> >> > > default for the C API, then it should be the default for the C++ as
>> >> well.
>> >> > >
>> >> > > What about a user conversion to TSCont in addition to an explicit
>> >> method?
>> >> > > If you could, writing this up as a Sphinx API doc would be cool.
>> >> > >
>> >> > > On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <
>> >> solidwallofcode@oath.com>
>> >> > > wrote:
>> >> > >
>> >> > >> Indirectly. What's stored in the Continuation is a shared pointer
>> to
>> >> the
>> >> > >> Mutex. That shared pointer is destructed by TSContDestroy which
>> may in
>> >> > turn
>> >> > >> destruct the Mutex (or not, if there are still references to it).
>> >> > >>
>> >> > >> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas
>> <wkaras@oath.com.invalid
>> >> >
>> >> > >> wrote:
>> >> > >>
>> >> > >>> I'm pretty sure TSContDestroy() also destroys any mutex for the
>> >> > >>> continuation. (Per our other discussion, I got exasperated
>> trying to
>> >> > >>> make sure of this looking through the code with just vi.)
>> >> > >>>
>> >> > >>>
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Derek
>>
>
>
>
> --
> Derek
Re: continuations in C++ API
Posted by Derek Dagit <de...@oath.com.INVALID>.
I think that would be better, because it's consistent with the current API.
Sorry if I wasn't clear on that before.
On Mon, Mar 19, 2018 at 4:07 PM, Walt Karas <wk...@oath.com.invalid> wrote:
> So is the upshot that the mutex param to the constructor should
> default to nullptr?
>
> On Mon, Mar 19, 2018 at 4:04 PM, Derek Dagit <de...@oath.com.invalid>
> wrote:
> > A continuation's Mutex is also used for certain API functions, like
> > TSHostLookup:
> >
> > https://docs.trafficserver.apache.org/en/latest/
> developer-guide/api/functions/TSHostLookup.en.html
> >
> > But you do not always need them.
> >
> > On Mon, Mar 19, 2018 at 3:48 PM, Alan Carroll <
> > solidwallofcode@oath.com.invalid> wrote:
> >
> >> Yes. I have seen reference count numbers in the high teens for some
> >> mutexes.
> >>
> >> On Mon, Mar 19, 2018 at 3:32 PM, Walt Karas <wk...@oath.com.invalid>
> >> wrote:
> >>
> >> > So it's possible that two different continuations may be sharing a
> single
> >> > mutex?
> >> >
> >> >
> >> > On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll
> >> > <so...@oath.com.invalid> wrote:
> >> > > Walt - I think Derek is commenting stylistically, that if no Mutex
> is
> >> the
> >> > > default for the C API, then it should be the default for the C++ as
> >> well.
> >> > >
> >> > > What about a user conversion to TSCont in addition to an explicit
> >> method?
> >> > > If you could, writing this up as a Sphinx API doc would be cool.
> >> > >
> >> > > On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <
> >> solidwallofcode@oath.com>
> >> > > wrote:
> >> > >
> >> > >> Indirectly. What's stored in the Continuation is a shared pointer
> to
> >> the
> >> > >> Mutex. That shared pointer is destructed by TSContDestroy which
> may in
> >> > turn
> >> > >> destruct the Mutex (or not, if there are still references to it).
> >> > >>
> >> > >> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas
> <wkaras@oath.com.invalid
> >> >
> >> > >> wrote:
> >> > >>
> >> > >>> I'm pretty sure TSContDestroy() also destroys any mutex for the
> >> > >>> continuation. (Per our other discussion, I got exasperated
> trying to
> >> > >>> make sure of this looking through the code with just vi.)
> >> > >>>
> >> > >>>
> >> >
> >>
> >
> >
> >
> > --
> > Derek
>
--
Derek
Re: continuations in C++ API
Posted by Walt Karas <wk...@oath.com.INVALID>.
So is the upshot that the mutex param to the constructor should
default to nullptr?
On Mon, Mar 19, 2018 at 4:04 PM, Derek Dagit <de...@oath.com.invalid> wrote:
> A continuation's Mutex is also used for certain API functions, like
> TSHostLookup:
>
> https://docs.trafficserver.apache.org/en/latest/developer-guide/api/functions/TSHostLookup.en.html
>
> But you do not always need them.
>
> On Mon, Mar 19, 2018 at 3:48 PM, Alan Carroll <
> solidwallofcode@oath.com.invalid> wrote:
>
>> Yes. I have seen reference count numbers in the high teens for some
>> mutexes.
>>
>> On Mon, Mar 19, 2018 at 3:32 PM, Walt Karas <wk...@oath.com.invalid>
>> wrote:
>>
>> > So it's possible that two different continuations may be sharing a single
>> > mutex?
>> >
>> >
>> > On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll
>> > <so...@oath.com.invalid> wrote:
>> > > Walt - I think Derek is commenting stylistically, that if no Mutex is
>> the
>> > > default for the C API, then it should be the default for the C++ as
>> well.
>> > >
>> > > What about a user conversion to TSCont in addition to an explicit
>> method?
>> > > If you could, writing this up as a Sphinx API doc would be cool.
>> > >
>> > > On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <
>> solidwallofcode@oath.com>
>> > > wrote:
>> > >
>> > >> Indirectly. What's stored in the Continuation is a shared pointer to
>> the
>> > >> Mutex. That shared pointer is destructed by TSContDestroy which may in
>> > turn
>> > >> destruct the Mutex (or not, if there are still references to it).
>> > >>
>> > >> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas <wkaras@oath.com.invalid
>> >
>> > >> wrote:
>> > >>
>> > >>> I'm pretty sure TSContDestroy() also destroys any mutex for the
>> > >>> continuation. (Per our other discussion, I got exasperated trying to
>> > >>> make sure of this looking through the code with just vi.)
>> > >>>
>> > >>>
>> >
>>
>
>
>
> --
> Derek
Re: continuations in C++ API
Posted by Derek Dagit <de...@oath.com.INVALID>.
A continuation's Mutex is also used for certain API functions, like
TSHostLookup:
https://docs.trafficserver.apache.org/en/latest/developer-guide/api/functions/TSHostLookup.en.html
But you do not always need them.
On Mon, Mar 19, 2018 at 3:48 PM, Alan Carroll <
solidwallofcode@oath.com.invalid> wrote:
> Yes. I have seen reference count numbers in the high teens for some
> mutexes.
>
> On Mon, Mar 19, 2018 at 3:32 PM, Walt Karas <wk...@oath.com.invalid>
> wrote:
>
> > So it's possible that two different continuations may be sharing a single
> > mutex?
> >
> >
> > On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll
> > <so...@oath.com.invalid> wrote:
> > > Walt - I think Derek is commenting stylistically, that if no Mutex is
> the
> > > default for the C API, then it should be the default for the C++ as
> well.
> > >
> > > What about a user conversion to TSCont in addition to an explicit
> method?
> > > If you could, writing this up as a Sphinx API doc would be cool.
> > >
> > > On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <
> solidwallofcode@oath.com>
> > > wrote:
> > >
> > >> Indirectly. What's stored in the Continuation is a shared pointer to
> the
> > >> Mutex. That shared pointer is destructed by TSContDestroy which may in
> > turn
> > >> destruct the Mutex (or not, if there are still references to it).
> > >>
> > >> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas <wkaras@oath.com.invalid
> >
> > >> wrote:
> > >>
> > >>> I'm pretty sure TSContDestroy() also destroys any mutex for the
> > >>> continuation. (Per our other discussion, I got exasperated trying to
> > >>> make sure of this looking through the code with just vi.)
> > >>>
> > >>>
> >
>
--
Derek
Re: continuations in C++ API
Posted by Alan Carroll <so...@oath.com.INVALID>.
Yes. I have seen reference count numbers in the high teens for some
mutexes.
On Mon, Mar 19, 2018 at 3:32 PM, Walt Karas <wk...@oath.com.invalid> wrote:
> So it's possible that two different continuations may be sharing a single
> mutex?
>
>
> On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll
> <so...@oath.com.invalid> wrote:
> > Walt - I think Derek is commenting stylistically, that if no Mutex is the
> > default for the C API, then it should be the default for the C++ as well.
> >
> > What about a user conversion to TSCont in addition to an explicit method?
> > If you could, writing this up as a Sphinx API doc would be cool.
> >
> > On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <so...@oath.com>
> > wrote:
> >
> >> Indirectly. What's stored in the Continuation is a shared pointer to the
> >> Mutex. That shared pointer is destructed by TSContDestroy which may in
> turn
> >> destruct the Mutex (or not, if there are still references to it).
> >>
> >> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas <wk...@oath.com.invalid>
> >> wrote:
> >>
> >>> I'm pretty sure TSContDestroy() also destroys any mutex for the
> >>> continuation. (Per our other discussion, I got exasperated trying to
> >>> make sure of this looking through the code with just vi.)
> >>>
> >>>
>
Re: continuations in C++ API
Posted by Walt Karas <wk...@oath.com.INVALID>.
So it's possible that two different continuations may be sharing a single mutex?
On Mon, Mar 19, 2018 at 1:37 PM, Alan Carroll
<so...@oath.com.invalid> wrote:
> Walt - I think Derek is commenting stylistically, that if no Mutex is the
> default for the C API, then it should be the default for the C++ as well.
>
> What about a user conversion to TSCont in addition to an explicit method?
> If you could, writing this up as a Sphinx API doc would be cool.
>
> On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <so...@oath.com>
> wrote:
>
>> Indirectly. What's stored in the Continuation is a shared pointer to the
>> Mutex. That shared pointer is destructed by TSContDestroy which may in turn
>> destruct the Mutex (or not, if there are still references to it).
>>
>> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas <wk...@oath.com.invalid>
>> wrote:
>>
>>> I'm pretty sure TSContDestroy() also destroys any mutex for the
>>> continuation. (Per our other discussion, I got exasperated trying to
>>> make sure of this looking through the code with just vi.)
>>>
>>>
Re: continuations in C++ API
Posted by Alan Carroll <so...@oath.com.INVALID>.
Walt - I think Derek is commenting stylistically, that if no Mutex is the
default for the C API, then it should be the default for the C++ as well.
What about a user conversion to TSCont in addition to an explicit method?
If you could, writing this up as a Sphinx API doc would be cool.
On Mon, Mar 19, 2018 at 1:01 PM, Alan Carroll <so...@oath.com>
wrote:
> Indirectly. What's stored in the Continuation is a shared pointer to the
> Mutex. That shared pointer is destructed by TSContDestroy which may in turn
> destruct the Mutex (or not, if there are still references to it).
>
> On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas <wk...@oath.com.invalid>
> wrote:
>
>> I'm pretty sure TSContDestroy() also destroys any mutex for the
>> continuation. (Per our other discussion, I got exasperated trying to
>> make sure of this looking through the code with just vi.)
>>
>>
Re: continuations in C++ API
Posted by Alan Carroll <so...@oath.com.INVALID>.
Indirectly. What's stored in the Continuation is a shared pointer to the
Mutex. That shared pointer is destructed by TSContDestroy which may in turn
destruct the Mutex (or not, if there are still references to it).
On Mon, Mar 19, 2018 at 12:56 PM, Walt Karas <wk...@oath.com.invalid>
wrote:
> I'm pretty sure TSContDestroy() also destroys any mutex for the
> continuation. (Per our other discussion, I got exasperated trying to
> make sure of this looking through the code with just vi.)
>
>
Re: continuations in C++ API
Posted by Walt Karas <wk...@oath.com.INVALID>.
I'm pretty sure TSContDestroy() also destroys any mutex for the
continuation. (Per our other discussion, I got exasperated trying to
make sure of this looking through the code with just vi.)
On Mon, Mar 19, 2018 at 10:23 AM, Derek Dagit <de...@oath.com.invalid> wrote:
> I might be missing the connection to the proposed Continuation constructor
> behavior with regard to the mutex.
>
> If there is a good reason to change this behavior, we should consider it.
> Otherwise it's probably best to keep consistency with the existing API.
>
> On Mon, Mar 19, 2018 at 10:16 AM, Walt Karas <wk...@oath.com.invalid>
> wrote:
>
>> The current C interface is bad because resources are not freed in
>> destructors, and the use of raw void pointers is necessary.
>>
>> On Mon, Mar 19, 2018 at 10:09 AM, Derek Dagit <de...@oath.com.invalid>
>> wrote:
>> > OK, so I am in favor of consistency with the existing C API, if possible
>> > and only if there is not good reason to break with the way the C API is
>> > doing it.
>> >
>> > On Mon, Mar 19, 2018 at 9:58 AM, Walt Karas <wk...@oath.com.invalid>
>> wrote:
>> >
>> >> yes
>> >>
>> >>
>> >> On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit <de...@oath.com.invalid>
>> >> wrote:
>> >> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
>> >> >
>> >> > Not every continuation requires a mutex. To get behavior similar to
>> the
>> >> > current C API we would need to pass a `nullptr` to the constructor,
>> >> right?
>> >> >
>> >> > On Fri, Mar 16, 2018 at 6:39 PM, Walt Karas <wk...@oath.com.invalid>
>> >> wrote:
>> >> >
>> >> >> Does this seem like a good wrapper class for continuations in the C++
>> >> API?
>> >> >>
>> >> >> class Continuation
>> >> >> {
>> >> >> public:
>> >> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
>> >> >> _cont(TSContCreate(_generalEventFunc, mutexp))
>> >> >> {
>> >> >> TSContDataSet(_cont, static_cast<void *>(this));
>> >> >> }
>> >> >>
>> >> >> TSCont
>> >> >> asTSCont() const
>> >> >> {
>> >> >> return _cont;
>> >> >> }
>> >> >>
>> >> >> void
>> >> >> destroy()
>> >> >> {
>> >> >> if (_cont) {
>> >> >> TSContDestroy(_cont);
>> >> >> _cont = nullptr;
>> >> >> }
>> >> >> }
>> >> >>
>> >> >> ~Continuation()
>> >> >> {
>> >> >> if (_cont) {
>> >> >> TSContDestroy(_cont);
>> >> >> }
>> >> >> }
>> >> >>
>> >> >> // No copying.
>> >> >> Continuation(const Continuation &) = delete;
>> >> >> Continuation &operator=(const Continuation &) = delete;
>> >> >>
>> >> >> // Moving allowed.
>> >> >> Continuation(Continuation &&that)
>> >> >> {
>> >> >> _cont = that._cont;
>> >> >> that._cont = nullptr;
>> >> >> }
>> >> >> Continuation &
>> >> >> operator=(Continuation &&that)
>> >> >> {
>> >> >> if (&that != this) {
>> >> >> if (_cont) {
>> >> >> TSContDestroy(_cont);
>> >> >> }
>> >> >> _cont = that._cont;
>> >> >> that._cont = nullptr;
>> >> >> }
>> >> >> return *this;
>> >> >> }
>> >> >>
>> >> >> explicit operator bool() const { return _cont != nullptr; }
>> >> >>
>> >> >> private:
>> >> >> // Distinct continuation behavior is achieved by overriding this
>> >> >> function in a derived continuation type.
>> >> >> //
>> >> >> virtual int _run(TSEvent event, void *edata) = 0;
>> >> >>
>> >> >> // This is the event function for all continuations in C++ plugins.
>> >> >> //
>> >> >> static int _generalEventFunc(TSCont cont, TSEvent event, void
>> *edata);
>> >> >>
>> >> >> TSCont _cont;
>> >> >> };
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Derek
>> >>
>> >
>> >
>> >
>> > --
>> > Derek
>>
>
>
>
> --
> Derek
Re: continuations in C++ API
Posted by Derek Dagit <de...@oath.com.INVALID>.
I might be missing the connection to the proposed Continuation constructor
behavior with regard to the mutex.
If there is a good reason to change this behavior, we should consider it.
Otherwise it's probably best to keep consistency with the existing API.
On Mon, Mar 19, 2018 at 10:16 AM, Walt Karas <wk...@oath.com.invalid>
wrote:
> The current C interface is bad because resources are not freed in
> destructors, and the use of raw void pointers is necessary.
>
> On Mon, Mar 19, 2018 at 10:09 AM, Derek Dagit <de...@oath.com.invalid>
> wrote:
> > OK, so I am in favor of consistency with the existing C API, if possible
> > and only if there is not good reason to break with the way the C API is
> > doing it.
> >
> > On Mon, Mar 19, 2018 at 9:58 AM, Walt Karas <wk...@oath.com.invalid>
> wrote:
> >
> >> yes
> >>
> >>
> >> On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit <de...@oath.com.invalid>
> >> wrote:
> >> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
> >> >
> >> > Not every continuation requires a mutex. To get behavior similar to
> the
> >> > current C API we would need to pass a `nullptr` to the constructor,
> >> right?
> >> >
> >> > On Fri, Mar 16, 2018 at 6:39 PM, Walt Karas <wk...@oath.com.invalid>
> >> wrote:
> >> >
> >> >> Does this seem like a good wrapper class for continuations in the C++
> >> API?
> >> >>
> >> >> class Continuation
> >> >> {
> >> >> public:
> >> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
> >> >> _cont(TSContCreate(_generalEventFunc, mutexp))
> >> >> {
> >> >> TSContDataSet(_cont, static_cast<void *>(this));
> >> >> }
> >> >>
> >> >> TSCont
> >> >> asTSCont() const
> >> >> {
> >> >> return _cont;
> >> >> }
> >> >>
> >> >> void
> >> >> destroy()
> >> >> {
> >> >> if (_cont) {
> >> >> TSContDestroy(_cont);
> >> >> _cont = nullptr;
> >> >> }
> >> >> }
> >> >>
> >> >> ~Continuation()
> >> >> {
> >> >> if (_cont) {
> >> >> TSContDestroy(_cont);
> >> >> }
> >> >> }
> >> >>
> >> >> // No copying.
> >> >> Continuation(const Continuation &) = delete;
> >> >> Continuation &operator=(const Continuation &) = delete;
> >> >>
> >> >> // Moving allowed.
> >> >> Continuation(Continuation &&that)
> >> >> {
> >> >> _cont = that._cont;
> >> >> that._cont = nullptr;
> >> >> }
> >> >> Continuation &
> >> >> operator=(Continuation &&that)
> >> >> {
> >> >> if (&that != this) {
> >> >> if (_cont) {
> >> >> TSContDestroy(_cont);
> >> >> }
> >> >> _cont = that._cont;
> >> >> that._cont = nullptr;
> >> >> }
> >> >> return *this;
> >> >> }
> >> >>
> >> >> explicit operator bool() const { return _cont != nullptr; }
> >> >>
> >> >> private:
> >> >> // Distinct continuation behavior is achieved by overriding this
> >> >> function in a derived continuation type.
> >> >> //
> >> >> virtual int _run(TSEvent event, void *edata) = 0;
> >> >>
> >> >> // This is the event function for all continuations in C++ plugins.
> >> >> //
> >> >> static int _generalEventFunc(TSCont cont, TSEvent event, void
> *edata);
> >> >>
> >> >> TSCont _cont;
> >> >> };
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Derek
> >>
> >
> >
> >
> > --
> > Derek
>
--
Derek
Re: continuations in C++ API
Posted by Walt Karas <wk...@oath.com.INVALID>.
The current C interface is bad because resources are not freed in
destructors, and the use of raw void pointers is necessary.
On Mon, Mar 19, 2018 at 10:09 AM, Derek Dagit <de...@oath.com.invalid> wrote:
> OK, so I am in favor of consistency with the existing C API, if possible
> and only if there is not good reason to break with the way the C API is
> doing it.
>
> On Mon, Mar 19, 2018 at 9:58 AM, Walt Karas <wk...@oath.com.invalid> wrote:
>
>> yes
>>
>>
>> On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit <de...@oath.com.invalid>
>> wrote:
>> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
>> >
>> > Not every continuation requires a mutex. To get behavior similar to the
>> > current C API we would need to pass a `nullptr` to the constructor,
>> right?
>> >
>> > On Fri, Mar 16, 2018 at 6:39 PM, Walt Karas <wk...@oath.com.invalid>
>> wrote:
>> >
>> >> Does this seem like a good wrapper class for continuations in the C++
>> API?
>> >>
>> >> class Continuation
>> >> {
>> >> public:
>> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
>> >> _cont(TSContCreate(_generalEventFunc, mutexp))
>> >> {
>> >> TSContDataSet(_cont, static_cast<void *>(this));
>> >> }
>> >>
>> >> TSCont
>> >> asTSCont() const
>> >> {
>> >> return _cont;
>> >> }
>> >>
>> >> void
>> >> destroy()
>> >> {
>> >> if (_cont) {
>> >> TSContDestroy(_cont);
>> >> _cont = nullptr;
>> >> }
>> >> }
>> >>
>> >> ~Continuation()
>> >> {
>> >> if (_cont) {
>> >> TSContDestroy(_cont);
>> >> }
>> >> }
>> >>
>> >> // No copying.
>> >> Continuation(const Continuation &) = delete;
>> >> Continuation &operator=(const Continuation &) = delete;
>> >>
>> >> // Moving allowed.
>> >> Continuation(Continuation &&that)
>> >> {
>> >> _cont = that._cont;
>> >> that._cont = nullptr;
>> >> }
>> >> Continuation &
>> >> operator=(Continuation &&that)
>> >> {
>> >> if (&that != this) {
>> >> if (_cont) {
>> >> TSContDestroy(_cont);
>> >> }
>> >> _cont = that._cont;
>> >> that._cont = nullptr;
>> >> }
>> >> return *this;
>> >> }
>> >>
>> >> explicit operator bool() const { return _cont != nullptr; }
>> >>
>> >> private:
>> >> // Distinct continuation behavior is achieved by overriding this
>> >> function in a derived continuation type.
>> >> //
>> >> virtual int _run(TSEvent event, void *edata) = 0;
>> >>
>> >> // This is the event function for all continuations in C++ plugins.
>> >> //
>> >> static int _generalEventFunc(TSCont cont, TSEvent event, void *edata);
>> >>
>> >> TSCont _cont;
>> >> };
>> >>
>> >
>> >
>> >
>> > --
>> > Derek
>>
>
>
>
> --
> Derek
Re: continuations in C++ API
Posted by Derek Dagit <de...@oath.com.INVALID>.
OK, so I am in favor of consistency with the existing C API, if possible
and only if there is not good reason to break with the way the C API is
doing it.
On Mon, Mar 19, 2018 at 9:58 AM, Walt Karas <wk...@oath.com.invalid> wrote:
> yes
>
>
> On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit <de...@oath.com.invalid>
> wrote:
> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
> >
> > Not every continuation requires a mutex. To get behavior similar to the
> > current C API we would need to pass a `nullptr` to the constructor,
> right?
> >
> > On Fri, Mar 16, 2018 at 6:39 PM, Walt Karas <wk...@oath.com.invalid>
> wrote:
> >
> >> Does this seem like a good wrapper class for continuations in the C++
> API?
> >>
> >> class Continuation
> >> {
> >> public:
> >> Continuation(TSMutex mutexp = TSMutexCreate()) :
> >> _cont(TSContCreate(_generalEventFunc, mutexp))
> >> {
> >> TSContDataSet(_cont, static_cast<void *>(this));
> >> }
> >>
> >> TSCont
> >> asTSCont() const
> >> {
> >> return _cont;
> >> }
> >>
> >> void
> >> destroy()
> >> {
> >> if (_cont) {
> >> TSContDestroy(_cont);
> >> _cont = nullptr;
> >> }
> >> }
> >>
> >> ~Continuation()
> >> {
> >> if (_cont) {
> >> TSContDestroy(_cont);
> >> }
> >> }
> >>
> >> // No copying.
> >> Continuation(const Continuation &) = delete;
> >> Continuation &operator=(const Continuation &) = delete;
> >>
> >> // Moving allowed.
> >> Continuation(Continuation &&that)
> >> {
> >> _cont = that._cont;
> >> that._cont = nullptr;
> >> }
> >> Continuation &
> >> operator=(Continuation &&that)
> >> {
> >> if (&that != this) {
> >> if (_cont) {
> >> TSContDestroy(_cont);
> >> }
> >> _cont = that._cont;
> >> that._cont = nullptr;
> >> }
> >> return *this;
> >> }
> >>
> >> explicit operator bool() const { return _cont != nullptr; }
> >>
> >> private:
> >> // Distinct continuation behavior is achieved by overriding this
> >> function in a derived continuation type.
> >> //
> >> virtual int _run(TSEvent event, void *edata) = 0;
> >>
> >> // This is the event function for all continuations in C++ plugins.
> >> //
> >> static int _generalEventFunc(TSCont cont, TSEvent event, void *edata);
> >>
> >> TSCont _cont;
> >> };
> >>
> >
> >
> >
> > --
> > Derek
>
--
Derek
Re: continuations in C++ API
Posted by Walt Karas <wk...@oath.com.INVALID>.
yes
On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit <de...@oath.com.invalid> wrote:
>> Continuation(TSMutex mutexp = TSMutexCreate()) :
>
> Not every continuation requires a mutex. To get behavior similar to the
> current C API we would need to pass a `nullptr` to the constructor, right?
>
> On Fri, Mar 16, 2018 at 6:39 PM, Walt Karas <wk...@oath.com.invalid> wrote:
>
>> Does this seem like a good wrapper class for continuations in the C++ API?
>>
>> class Continuation
>> {
>> public:
>> Continuation(TSMutex mutexp = TSMutexCreate()) :
>> _cont(TSContCreate(_generalEventFunc, mutexp))
>> {
>> TSContDataSet(_cont, static_cast<void *>(this));
>> }
>>
>> TSCont
>> asTSCont() const
>> {
>> return _cont;
>> }
>>
>> void
>> destroy()
>> {
>> if (_cont) {
>> TSContDestroy(_cont);
>> _cont = nullptr;
>> }
>> }
>>
>> ~Continuation()
>> {
>> if (_cont) {
>> TSContDestroy(_cont);
>> }
>> }
>>
>> // No copying.
>> Continuation(const Continuation &) = delete;
>> Continuation &operator=(const Continuation &) = delete;
>>
>> // Moving allowed.
>> Continuation(Continuation &&that)
>> {
>> _cont = that._cont;
>> that._cont = nullptr;
>> }
>> Continuation &
>> operator=(Continuation &&that)
>> {
>> if (&that != this) {
>> if (_cont) {
>> TSContDestroy(_cont);
>> }
>> _cont = that._cont;
>> that._cont = nullptr;
>> }
>> return *this;
>> }
>>
>> explicit operator bool() const { return _cont != nullptr; }
>>
>> private:
>> // Distinct continuation behavior is achieved by overriding this
>> function in a derived continuation type.
>> //
>> virtual int _run(TSEvent event, void *edata) = 0;
>>
>> // This is the event function for all continuations in C++ plugins.
>> //
>> static int _generalEventFunc(TSCont cont, TSEvent event, void *edata);
>>
>> TSCont _cont;
>> };
>>
>
>
>
> --
> Derek
Re: continuations in C++ API
Posted by Derek Dagit <de...@oath.com.INVALID>.
> Continuation(TSMutex mutexp = TSMutexCreate()) :
Not every continuation requires a mutex. To get behavior similar to the
current C API we would need to pass a `nullptr` to the constructor, right?
On Fri, Mar 16, 2018 at 6:39 PM, Walt Karas <wk...@oath.com.invalid> wrote:
> Does this seem like a good wrapper class for continuations in the C++ API?
>
> class Continuation
> {
> public:
> Continuation(TSMutex mutexp = TSMutexCreate()) :
> _cont(TSContCreate(_generalEventFunc, mutexp))
> {
> TSContDataSet(_cont, static_cast<void *>(this));
> }
>
> TSCont
> asTSCont() const
> {
> return _cont;
> }
>
> void
> destroy()
> {
> if (_cont) {
> TSContDestroy(_cont);
> _cont = nullptr;
> }
> }
>
> ~Continuation()
> {
> if (_cont) {
> TSContDestroy(_cont);
> }
> }
>
> // No copying.
> Continuation(const Continuation &) = delete;
> Continuation &operator=(const Continuation &) = delete;
>
> // Moving allowed.
> Continuation(Continuation &&that)
> {
> _cont = that._cont;
> that._cont = nullptr;
> }
> Continuation &
> operator=(Continuation &&that)
> {
> if (&that != this) {
> if (_cont) {
> TSContDestroy(_cont);
> }
> _cont = that._cont;
> that._cont = nullptr;
> }
> return *this;
> }
>
> explicit operator bool() const { return _cont != nullptr; }
>
> private:
> // Distinct continuation behavior is achieved by overriding this
> function in a derived continuation type.
> //
> virtual int _run(TSEvent event, void *edata) = 0;
>
> // This is the event function for all continuations in C++ plugins.
> //
> static int _generalEventFunc(TSCont cont, TSEvent event, void *edata);
>
> TSCont _cont;
> };
>
--
Derek