> 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 wrote:
> Does this seem like a good wrapper class fo
yes
On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit 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 P
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 wrote:
> yes
>
>
> On Mon, Mar 19, 2018 at 9:54 AM, Derek Dagit
> wrote:
> >> Continuation(TSMu
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 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 b
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 Ka
https://cwiki.apache.org/confluence/display/TS/CommitPolicies
Some of these wiki topics look outdated.
Should we update them, or even remove them to avoid confusion?
--
Derek
Updates welcome! You should be able to get write access to the Wiki now.
Why do we use both reStructuredText and wiki formats? Is there a
freeware WYSIWYG word processor that can vomit out both?
On Mon, Mar 19, 2018 at 11:34 AM, Alan Carroll
wrote:
> Updates welcome! You should be able to get write access to the Wiki now.
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 wrote:
> I might be missing the connection to the proposed
As you can see from the dust on the wiki, we don't really use wiki format.
We use Sphinx / Restructured Text because doing technical documentation in
a Wiki is (IMHO) infeasible. It used to be worse, back when we used the
Apache CMS for documentation, which required both another source repository
a
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
wrote:
> I'm pretty sure TSContDestr
> 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 def
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, Ma
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
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 a
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 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
> wrote:
> > Walt - I think De
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 <
solidwallofc...@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 wrote:
> A continuation's Mutex is also used for certain API functions, like
> TSHostLookup:
>
> https://docs.trafficserver.apache.org/en/latest/developer-guide/api/fun
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 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, Der
Or maybe no default to avoid confusion?
On Mon, Mar 19, 2018 at 4:08 PM, Derek Dagit 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 wrote:
>
>> So is the upshot that
> 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 wrote:
> Or maybe no default to avoid confusion?
>
> On Mon, Mar 19, 2018 at 4:08 PM, Derek Dagit
> wrote:
> > I think that would be better, because it's consistent with the c
Fei (duke8253) found a number of leaks doing the jemalloc work for 8.0. I
wouldn't expect any of those fixes to get back ported to 6.x. You might
search his PRs to see them.
On Thu, Mar 15, 2018 at 7:51 PM, Shu Kit Chan wrote:
> I tried some memory leak debugging with jemalloc before.
>
> The ex
21 matches
Mail list logo
