Assert when sm callback to wrong thread

[scw00]

The plugin might schedule the sm to task thread. And it will crash here because task thread doses not have thread session pool.

static int
task_cont_handler(TSCont contp, TSEvent event, void *edata)
{
  TSHttpTxn txn = (TSHttpTxn)TSContDataGet(contp);
  TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
  TSContDestroy(contp);
  return 0;
}

static int
cont_handler(TSCont contp, TSEvent event, void *edata)
{

  auto cont = TSContCreate(task_cont_handler, TSMutexCreate());
  TSContDataSet(cont, edata);
  TSContScheduleOnPool(cont, 0, TS_THREAD_POOL_TASK);
  return 0;
}

void
TSPluginInit(int argc, const char *argv[])
{
  TSPluginRegistrationInfo info;

  info.plugin_name   = PLUGIN_NAME;
  info.vendor_name   = "Apache Software Foundation";
  info.support_email = "dev@trafficserver.apache.org";

  if (TSPluginRegister(&info) != TS_SUCCESS) {
    TSError("[%s] Plugin registration failed", PLUGIN_NAME);
  }

  TSDebug(PLUGIN_NAME, "Hello World!");

  TSHttpHookAdd(TS_HTTP_SEND_RESPONSE_HDR_HOOK, TSContCreate(cont_handler, TSMutexCreate()));
}

[scw00]

Updated for @oknet's suggestion. We limit the thread when we callback. I have no idea which one would be better .

[shinrich]

Alternatively should the InkAPI call just reschedule to an ET NET thread if it lands on the wrong type fo thread?

[bryancall]

I would rather have the plugin assert instead of having a bug in the plugin and it going unnoticed because we are fixing things up under the hood.

[zwoop]

Agreed. @shinrich How does this relate to the other changes that were done with regards to locks (mutexes) and automatically acquire those in many cases ?

[oknet]

Agreed with @shinrich , the TSHttpSMCallback is designed to reenable HttpSM from the correct EThread.

By TS-2271, TSHttpTxnReenable() can be called from a thread which was not created using the ATS EThread API.

Now we can also allow TSHttpTxnReenable() to be called from an EThread outside of ET_NET.

[shinrich]

I think this is unrelated to the auto-locking concerns. This code is already handling the reschedule. The original code would reschedule for any non REGULAR thread. The changes will now reschedule for any non REGULAR or non ET_NET threads.

So the case that will now be rescheduled that wouldn't have been in the original would be REGULAR threads that are not ET_NET. So the added assert should not ever trigger.

Still looks good to me.

[bryancall]

Cherry picked to 8.1.0