[
https://issues.apache.org/jira/browse/TS-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193405#comment-15193405
]
Alan M. Carroll commented on TS-4265:
-------------------------------------
Moving the per thread type initialization to {{EventProcessor}} was also
motivated by dependency analysis. {{EThread}} knows nothing about thread types
and enlightening it seemed to be introducing yet another circular dependency.
Unfortunately there is much more thread initialization going on than I
anticipated and so the changes are more extensive than expected.
> Provide per EThread and per event type thread initialization.
> -------------------------------------------------------------
>
> Key: TS-4265
> URL: https://issues.apache.org/jira/browse/TS-4265
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Fix For: 6.2.0
>
>
> As far as I can tell, {{EThread::schedule_spawn}} is is not used and is just
> a crippled version of {{EThread::schedule_imm}} without the optional
> arguments.
> It would be better to make this call provide a mechanism to schedule
> continuations that are called when a thread is spawned. This enable a lot of
> cleanup of some very ugly thread initialization logic while at the same time
> avoiding potential ugly race conditions. For instance {{NetHandler}} is
> initialized in each thread *after* the thread is already running but before
> (hopefully) any I/O events arrive. It would be much cleaner to do that in a
> thread spawn event. Further this would decouple some initialization logic and
> thread logic (as in this case) - the initalization logic would no longer need
> to know anything about thread start up other than {{EThread::schedule_spawn}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
