Github user JoshRosen commented on the pull request:
https://github.com/apache/spark/pull/4871#issuecomment-77034073
> This line should have prevented 2 threads from going into the inner {...}
and thefore changing the order of the lines wouldn't help.
I think the original issue here was that two sequential calls to `stop()`
could cause spurious errors / warnings to occur, e.g.
```
sc.stop()
// ---- other stuff -----
sc.stop()
```
This can happen when `sc.stop()` is called in `finally` blocks; there are
many cases that can lead to `stop()` being called twice on the same
SparkContext, so it makes sense to have it be idempotent.
@srowen I'm not quite sure why `stopped` is set after posting the
application end event or stopping the UI. Before I introduced the `stopped`
variable, the old code would set `dagScheduler = null` and check that field's
value to determine whether the SparkContext had stopped. That old code had the
same property, so maybe there's a good reason why things were ordered this way
(or maybe not; this could just be some vestigial artifact of how the code
evolved over time).
---
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]
