Re: Hash containers - some thoughts and recommendations

2018-08-14 Thread Aaron Canary
https://github.com/apache/trafficserver/pull/4110 I have also written a hashtable, intended to be an atomic map and contain atomic elements. read/write concurrency is handled per member of elements with AcidPtr. In your example "if the object has an FQDN and an IP address" then both tables contain

Re: Hash containers - some thoughts and recommendations

2018-08-14 Thread Alan Carroll
What happens if one table is updated, but the other isn't? Is that permitted by the API? This does remind me that one issue with intrusive maps is that it is much harder to protect the key from changes. On Tue, Aug 14, 2018 at 4:20 PM Aaron Canary wrote: > https://github.com/apache/trafficserver

[New API Proposal] TSContScheduleToCurrentThread and TSContScheduleToCurrentThreadEvery

2018-08-14 Thread zzz
Hi, team, The background here is we'd like to clean up a thread local cache after some timeout. Unfortunately, we're lacking an API to schedule a continuation to the current thread. There are two ways I can think of to achieve this. One is a pair of new APIs *TSContScheduleToCurrentThread(TSCont

Re: [New API Proposal] TSContScheduleToCurrentThread and TSContScheduleToCurrentThreadEvery

2018-08-14 Thread Kees Spoelstra
+1, we currently have it implemented but did not come around to make a pull request and a proposal. Some remarks, instead of current thread we should be able to schedule on an arbitrary thread (*OnThread) This can also improve performance by preventing thread jumping and provide simpler concurren

Re: [New API Proposal] TSContScheduleToCurrentThread and TSContScheduleToCurrentThreadEvery

2018-08-14 Thread Otto van der Schaaf
+1 for APIs that allow scheduling on an arbitrary thread On Wed, 15 Aug 2018 at 03:37, Kees Spoelstra wrote: > +1, we currently have it implemented but did not come around to make a pull > request and a proposal. > > Some remarks, instead of current thread we should be able to schedule on an > a