TSCont TSContWhenCreate(TSEventFunc funcp, TSMutex mutexp); With this change, TSCont objects will have an implicit "retry" flag. The retry flag will be true when the TSCont is created with TSContWhenCreate(). The flag will be false when the TSCont is created with TSContCreate().
If the retry flag is true, and the TCont is placed on a hook, the return value from the TSCont's event function will no longer be a don't care. IIt must be one of TS_EVENT_NULL, TS_EVENT_CONTINUE or TS_EVENT_ERROR. The event function must not call any reenable function. If the event function returns TS_EVENT_NULL, the event thread will try to execute all the other continuations in its event queue (without unlocking the TSCont's mutex, if any), then it will execute the TSCont again. If the event function returns TS_EVENT_CONTINUE, the execution of the TSCont is complete. If the event function returns TS_EVENT_ERROR, the execution of TSCont completed due to some fatal error. This capability is useful when the event function needs to call a function that may block. This would block the event thread the continuation is running on. The retry capability allows the event function to either: 1) call the equivalent non-blocking function, or 2) dynamically spawn a thread that does the blocking call, and wait for the thread to complete. This new capability would eliminate the need for the technique illustrated by this proposed new Au test: https://github.com/apache/trafficserver/pull/9044 . Not calling reenable functions would reduce stack depth and thus improve locality of reference. We could consider also adding a function that returns the value of the retry flag for a TSCont: int TSContRetryFlag(TSCont contp);
