Re: [NEW API Proposal] TSThreadCreateWithSignalling

2020-03-04 Thread Alan Carroll
This seems reasonable and there's no apparent opposition, I think we should proceed. On Fri, Feb 28, 2020 at 2:21 PM Fei Deng wrote: > Recently while dealing with shutdown crashes related to plugins, I found a > way to have individual threads process signals with their own signal > handlers. Aft

Re: [API Proposal] Global Arg slots

2020-03-04 Thread Leif Hedstrom
> On Feb 27, 2020, at 10:13 AM, Leif Hedstrom wrote: > > Hi all, > > This is an idea from Bryan Call, which he suggested as a solution for > reloadable plugins changes that are now in 9.0.x. I recently ran into a > different use case (thanks Miles …), which could really benefit (performance

TSFetchUrl support for dechunking in HTTP/1.1

2020-03-04 Thread Sudheer Vinukonda
We use TSFetchUrl() API in a bunch of our use cases to trigger sideways calls. The API by default sets `TS_FETCH_FLAGS_DECHUNK`,which implies the response returned is dechunked. There's another flag called 'TS_FETCH_FLAGS_STREAM' in FechSM, which is NOT set by default.  This makes TSFetchUrl API

Re: [API Proposal] Global Arg slots

2020-03-04 Thread Walt Karas
So why do you like this? - Breaks lots of existing code. - Less typesafe. - Makes use more verbose. It's good how the API has avoided the use of void pointers. We should not reverse that design goal. On Wed, Mar 4, 2020 at 12:03 PM Leif Hedstrom wrote: > > > > On Feb 27, 2020, at 10:13 AM, Le

Re: [API Proposal] Global Arg slots

2020-03-04 Thread Leif Hedstrom
> On Mar 4, 2020, at 11:17 AM, Walt Karas > wrote: > > So why do you like this? - Less code - Fewer APIs - Generalizes the concept I don’t feel super strongly about the Get() / Set()’ers, I can definitely retain the underlying core changes (which are good), and keep (and add more) of the

Re: [API Proposal] Global Arg slots

2020-03-04 Thread Alan Carroll
I like thinner and more automatic APIs. This is less typing overall, because the Get/Set functions don't require a type name in them. It also makes it easier to add or remove object args. Also, in the longer term (ATS 10) we should move to Extendible anyway, which provides real type safety. On Wed

Re: [API Proposal] Global Arg slots

2020-03-04 Thread Walt Karas
Instead of int argument indexes, how about argument IDs of type: typedef struct { TSUserArgType type; short idx; } TSUserArgIDType; This would allow for more run-time type checking. On Wed, Mar 4, 2020 at 12:40 PM Alan Carroll wrote: > I like thinner and more automatic APIs. This is less

Re: [API Proposal] Global Arg slots

2020-03-04 Thread Leif Hedstrom
> On Mar 4, 2020, at 12:18 PM, Walt Karas > wrote: > > Instead of int argument indexes, how about argument IDs of type: > > typedef struct > { > TSUserArgType type; > short idx; > } TSUserArgIDType; > > This would allow for more run-time type checking. Not sure I follow that… The type