illissius at gmail.com
Tue Jun 12 13:38:09 CEST 2012
On Tue, Jun 12, 2012 at 12:58 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> I think that now addresses all the comments that people had.
> There's one more change I'm thinking about: perhaps instead of
> wait :: Async a -> IO (Either SomeException a)
> waitThrow :: Async a -> IO a
> we should reverse the naming scheme, rename waitThrow to wait and wait to
> something else (waitCatch?). Rationale: waitThrow seems to be the version
> we need most often, and it's simpler to use.
> wait :: Async a -> IO a
> waitCatch :: Async a -> IO (Either SomeException a)
> Thoughts? Better names for waitCatch?
> Latest Haddocks:
Two small ones:
- In the documentation for cancel: "Has no effect if the Async has
already", it seems like something might have been cut off.
- Can we find a more accurate name for tryWait? It doesn't try and
possibly fail to wait, it avoids waiting altogether. Maybe don'tWait,
although that doesn't say what it does do. The only other idea I have
is 'check' which is not very descriptive...
>> On 8 June 2012 09:37, Simon Marlow<marlowsd at gmail.com> wrote:
>>> I'd like to add a higher-level concurrency API to the base package. This
>>> has grown while I've been working on examples for my book, and I'm
>>> that we should have something like this in the standard libraries.
>>> the API I propose:
>>> In fact it already exists in at least two packages on Hackage: 'async'
>>> 'threads'. My version is a superset of both of these, except for a few
>>> small differences (which are up for discussion, of course).
>>> One good reason to have this package is that it avoids some common
>>> such as forgetting to handle exceptions in your child threads. In the
>>> API, you get to choose whether to (a) receive the result as 'Either
>>> SomeException a', or (b) have the exception re-thrown in the waiting
>>> You don't get to ignore it altogether.
>>> Another common pitfall avoided by this library is accidentally leaving
>>> threads running in the background. This is handled by withAsync:
>>> withAsync :: IO a -> (Async a -> IO b) -> IO b
>>> the child thread is always cancelled (i.e. killed) when the second
>>> returns or throws an exception, if it hasn't finished already.
>>> I'm opening this up for discussion so that we can tidy up any
>>> details and add any functions that people feel are missing. Naming is
>>> obviously up for discussion too.
>>> Libraries mailing list
>>> Libraries at haskell.org
> Libraries mailing list
> Libraries at haskell.org
Work is punishment for failing to procrastinate effectively.
More information about the Libraries