Yes, we have seen something similar to this in the last week or so. By the
time we deployed a build that fetches the hdrp on each call and asserts if
the differ, the crashes we had been seeing cleared up.
I will review my notes on this when I get back to the office tomorrow.
Susan
On Wed, Nov 2
Hi All,
We experienced some core dumps in ATS 7.1.4. My question is whether the pointers
returned by TSHttpTxnServerReqGet() might ever become invalid over the life of
the transaction?
The core dump occurred from the Lua plugin in the
ts_lua_server_request_header_set() function --
if (!http_c
Ah, missed some other stuff.
The bug we've seen is one that's not always visible, particularly on busy
systems, because the event loop never waits very long. However, in the
particular use case here, the systems are sufficiently lightly loaded and
the latency requirements sufficiently strict that
For event processing style programming, it's standard to have two event
scheduling "styles" - an immediate "do as soon as possible", and a
"scheduled" style which is guaranteed to unwind the event processing stack
at least once. In another way, it's similar to "call" and "yield" in
co-routines. I w
it's not a bug, it's how it was supposed to be from the beginning but
wasn't functioning correctly.
On Wed, Nov 20, 2019 at 2:27 PM Sudheer Vinukonda
wrote:
> >>> that will cause an issue for devs that are using
> schedule with 0 timeouts in their code to schedule itself over and over
> again (
>>> that will cause an issue for devs that are using
schedule with 0 timeouts in their code to schedule itself over and over
again (see test code in PR comment), which is bad programming on their part
but it might happen and is a valid concern.
So, isn't this a new bug introduced with PR# 6103?
It's not a hole, it's how it should have been all along, but have not been
working properly for a long time. schedule_imm is supposed to put things in
queue and have the eventloop process them asap and not waiting for IO or
other stuff, but instead it stays in queue till we wake up the thread
eithe
Leif,
While not required for ATS 9.0, I'd like to see the next hop
strategies/remap in 9.0. It's a new feature that may be used and is
currently targeted for 9.1. Is there any reasons it can't go into 9.0?
The relevant PR's are:
5960: Add Nexthop selection strategies and @strategy tag to remap
The assembler shows that initialization is just immediate stores (of zero
in this case). So memcpy of the proto object should load in the same
constant values.
On Wed, Nov 20, 2019 at 12:49 PM Alan Carroll
wrote:
> That doesn't seem to account for the proto object used in the class
> allocator.
That doesn't seem to account for the proto object used in the class
allocator. I think you might be OK with std::unique_ptr anyway, because it
default constructs to a nullptr.
On Wed, Nov 20, 2019 at 12:03 PM Walt Karas
wrote:
> Does this, https://godbolt.org/z/4muzR3 , satisfy everyone that ins
Does this, https://godbolt.org/z/4muzR3 , satisfy everyone that instances
of std::unique_ptr can be member variables of classes with class allocators
(as long as ~unique_ptr() is explicitly called in the destroy function)?
Kvetch now or forever hold your kvetch.
Hmm..Why’d the API need to differentiate the implementation details to users?
Alternately, why’d someone pick an API that may have a hole?
I haven’t fully analyzed and understood the proposed changes, but having two
different API that only differ in how they are implemented under the hood (and
Let me rephrase that, the new API behaves the same as the TSContSchedule
with 0 timeout after PR#6103, which will handle events as soon as possible.
While this is good for delays, it also causes the situation scw00 brought
up (dead loop). And since there is no good way of differentiating this
behav
13 matches
Mail list logo
