summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJoey Hess2015-10-21 16:50:38 -0400
committerJoey Hess2015-10-21 16:50:38 -0400
commit061e66e0d8d22105f99e806efcfa2c86a211e3f1 (patch)
tree23c61184ba7206fbf3bdf19bb2e563458af39fa8 /doc
parentbd6bbcf8ce366cb212156a9f216b68c1dc685e57 (diff)
thoughts
Diffstat (limited to 'doc')
-rw-r--r--doc/todo/concurrency.mdwn63
1 files changed, 53 insertions, 10 deletions
diff --git a/doc/todo/concurrency.mdwn b/doc/todo/concurrency.mdwn
index 7de60d5c..712747f0 100644
--- a/doc/todo/concurrency.mdwn
+++ b/doc/todo/concurrency.mdwn
@@ -7,27 +7,51 @@ Another version also nice to have:
race :: IsProp p => p -> p -> p
-Implementation should be pretty easy; propellor does not have a lot of
+Basic implementation should be pretty easy; propellor does not have a lot of
mutable state to get in the way.
The only hard part is, ensuring a property may cause arbitrary output,
and it's not line-buffered necessarily, so there could be messy
interleaving. I'm not sure how to deal with this, short of forking
-off a sub-process to ensure the property.
+off a sub-process to ensure the property.
-And, how would that sub-process be told which property it's supposed to
+----
+
+If forkProcess could be used, it could fork a subprocess that knows the
+action it's to perform, and jiggers stdio to feed through a pipe back to the
+parent. But, I have had bad luck in the past using forkProcess in haskell,
+in combination with the -threaded runtime.
+
+---
+
+Instead, execing a new process would work. But, how to tell that
+sub-process be told which property it's supposed to
ensure? There's no property serialization, and not even a Eq to use.
Hmm, if it could come up with a stable, unique Id for each property, then
the sub-process could be told the Id, and it'd then just look through its
-Host to find the property. This could be done by propellor's defaultMain,
-using Data.Unique (or a reimplementation that lets us get at the actual
-integer, rather than a hash of it). As long as it processes properties in a
-consistent order, that will generate the same Id for a property each time
-(until propellor is recompiled of course). The Id can be paired with the
-description of the property, to catch any version skew.
+Host to find the property.
+
+This could be done by propellor's defaultMain, using Data.Unique (or a
+reimplementation that lets us get at the actual integer, rather than a hash
+of it). As long as it processes properties in a consistent order, that will
+generate the same Id for a property each time (until propellor is
+recompiled of course). The Id can be paired with the description of the
+property, to catch any version skew.
+
+But, this seems to not get all the way there. Having Id's for the top-level
+properties doesn't help in a situation like:
+
+ & propertyList "foo"
+ [ x `race` y
+ , a `race` b
+ ]
-What about mixing concurrently with ensureProperty?
+x y a b are not top-level properties of a Host, so won't get unique Id's.
+Unless we can build up some tree of Id's that can be walked from the
+top-level down to the sub-properties, this won't work. Help?
+
+Also, what about mixing concurrently with ensureProperty?
foo = property "foo" $ do
liftIO defCon5
@@ -44,4 +68,23 @@ special exit code that it couldn't find the requested Id, and then `race`
can just wait for missleDefense to finish, and then run diplomacy.
(Granted, this order may not be ideal in this specific case..)
+----
+
+Final option is to say, there are two sources of output when
+ensuring a property:
+
+* Propellor's own output, which is mostly gated through a few functions,
+ although of course the user can print anything they want too.
+* Output from running commands. Mostly done via cmdProperty, although
+ the user's also free to run commands in other ways.
+
+So, the Propellor monad could have a flag added to say that all output
+should be captured rather than output now, and just do that on a
+best-effort basis.
+
+Could even redirect stderr and stdout to a pipe, to capture any errant
+output. We'd not be able to tell which of the concurrent actions was
+responsible for such output, but it could be printed out, with appropriate
+warnings, at the end.
+
[[!tag user/joey]]