[
https://issues.apache.org/jira/browse/TS-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187444#comment-15187444
]
Alan M. Carroll commented on TS-4265:
-------------------------------------
This has mutated a bit. I am now updating {{EventProcessor}} to provide per
thread type initialization which I think is a better approach.
{{EThread::schedule_spawn}} will now take just a single continuation which gets
called at thread spawn for {{REGULAR}} threads. {{EventProcessor}} then uses
that to do its own initialization and call per type initialization. There is no
conflict because {{EventProcessor}} both creates and starts the threads so
nothing else could usefully call {{EThread::schedule_spawn}} on those threads
in any case.
> Repurpose EThread::schedule_spawn to actually schedule at thread spawn
> ----------------------------------------------------------------------
>
> 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
>
> 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)
