Github user JoshRosen commented on the pull request:
https://github.com/apache/spark/pull/5277#issuecomment-87876766
Hmm, good points.
In the case of the race reported in the original JIRA, I guess the main
thread's `SparkContext.stop()` call wins, so the EventLoop thread would lose
and throw the timeout exception, unblocking the main thread and allowing it to
finish cleanup. If the locks were acquired in the other order, then I guess
that the EventLoop would wind up trying to `join()` on its own thread. Based
on http://stackoverflow.com/questions/5999595/thread-join-on-itself, it sounds
like this is not safe. Do you think that we should guard against this by
checking the current thread id in `EventLoop.stop()` before calling join()?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
