vanzin commented on a change in pull request #25951: [SPARK-28917][CORE]
Synchronize access to RDD mutable state.
URL: https://github.com/apache/spark/pull/25951#discussion_r331219364
##########
File path: core/src/main/scala/org/apache/spark/rdd/RDD.scala
##########
@@ -103,6 +103,17 @@ abstract class RDD[T: ClassTag](
_sc
}
+ /**
+ * Lock for all mutable state of this RDD (persistence, partitions,
dependencies, etc.). We do
+ * not use `this` because RDDs are user-visible, so users might have added
their own locking on
+ * RDDs; sharing that could lead to a deadlock.
+ *
+ * One thread might hold the lock on many of these, for a chain of RDD
dependencies; but
+ * because DAGs are acyclic, and we only ever hold locks for one path in
that DAG, there is no
+ * chance of deadlock.
+ */
+ private val stateLock = new SerializableObject()
Review comment:
Actually RDDs are serialized as part of computing them on executors.
But I'm not sure if there are well-defined semantics about what is safe to
access in executors. For example, if your custom RDD tries to access
`dependencies` on the executor side, is it guaranteed that it will be
available? Because actually calculating the dependencies seems like something
only the driver can do.
(`partitions_` is `@transient` so it seems clear that it's not to be used
in executors).
My gut feeling is that all of these things should be transient; it feels
that `RDD.compute` really should be independent of any (Spark-internal) state
in the RDD class. But it's hard to say if that's really safe to enforce at this
point, with so many years of people writing their own RDDs.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
