Optimize: rewrite getbyname_imm and getSRVbyname_imm as wrappers for getby

[oknet]

No description provided.

[scw00]

LGTM ..

[oknet]

The workflow after PR #4916

The workflow with this PR #4961

[SolidWallOfCode]

A couple of alternatives.

force_dns = host_db_re_dns_on_reload;

or

if (hostdb_re_dns_on_reload) {
  force_dns = true;
  HOST_DB_INCREMENT_DYN_STAT(..);
}

[oknet]

updated

[SolidWallOfCode]

This could be a deadlock concern, if the thread blocks on acquiring a lock.

[oknet]

I just rewrote SCOPED_MUTEX_LOCK(lock, bucket_mutex, thread);.

[oknet]

Please check the TS-374 commit via ba3b7d0.

It solves a performance issue of reverse proxy.

[SolidWallOfCode]

Overall I like the cleanup, but I'm quite concerned about the blocking lock. I don't see why

(cont->*cb_process_result)(r.get())

cannot be bound in to the HostDBContinuation if the lock isn't acquired. The continuation can be given the bucket mutex as its mutex, then it need merely try for lock2 to call the function.

[oknet]

@SolidWallOfCode

IMO, the (cont->*cb_process_result)(r.get()) may be a fast path than reply_to_cont(cont, r).

[SolidWallOfCode]

Clearly, which is the reason to do a try lock. But if that fails, hard locking and creating blockage from lock contention is the slow path.

[oknet]

@SolidWallOfCode
May I merge this PR first? Because it does not change the logic.
And then open a new issue to discuss the TS-374 (commit ba3b7d0) and (cont->*cb_process_result)(r.get()).

The SCOPED_MUTEX_LOCK and (cont->*cb_process_result)(r.get()) are the only differences between the getbyname_re and the getbyname_imm interfaces.

[oknet]

[approve ci autest]

[vmamidi]

@oknet I like the code cleanup but i think we might still encounter deadlock like this( #1335 ) even after the cleanup. #1756 avoids such scenarios but it doesn't prevent anyone from accidentally causing a dead lock similar to ( #1335 ).

[oknet]

@vmamidi

I will find a new solution to the TS-374 and replace the commit ba3b7d0.

It will use MUTEX_TRY_LOCK completely to avoid the deadlocks.

[oknet]

@SolidWallOfCode @vmamidi
I merged this and open an issue #5043 to discuss the deadlock problem and the solution.