diff options
| author | Joey Hess <joeyh@joeyh.name> | 2015-10-21 16:23:38 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2015-10-21 16:23:38 -0400 |
| commit | 95f4a9b160f74f7478558ceb1c9c2b2bab9360bf (patch) | |
| tree | d9a9f9a72f4b72311985acd9eb86876943c988b2 /doc/todo/concurrency.mdwn | |
| parent | cdbcc52cae1bfbbc8a685a463f5f97c73fd5e4c6 (diff) | |
todo
Diffstat (limited to 'doc/todo/concurrency.mdwn')
| -rw-r--r-- | doc/todo/concurrency.mdwn | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/doc/todo/concurrency.mdwn b/doc/todo/concurrency.mdwn new file mode 100644 index 00000000..7de60d5c --- /dev/null +++ b/doc/todo/concurrency.mdwn @@ -0,0 +1,47 @@ +Should be possible to add this, to construct a bunch of properties and +run them in parallel: + + concurrently :: IsProp p => (a -> p) -> [a] -> p + +Another version also nice to have: + + race :: IsProp p => p -> p -> p + +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. + +And, how would 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. + +What about mixing concurrently with ensureProperty? + + foo = property "foo" $ do + liftIO defCon5 + ensureProperty $ + missleDefense `race` diplomacy + where + missleDefense = ... + diplomacy = ... + +Here there's no way for a propellor sub-process to know it needs to +run part of foo to get to diplomacy. I think it would be ok to fall back to +sequential mode in this case. So, the sub-process could signal with a +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..) + +[[!tag user/joey]] |
