In my opinion, if there is a timeout, the whole thing should fail. With pmap, we are the ones adding the new avenue for error; therefore, I think we should mimic behavior of map as much as possible and completely bail on errors that occur from additional processing that is done because of the parallel nature.
As a compromise though, I think pmap should do that behavior. There is no reason why we can't have a pmap that takes the option of not failing on timeouts. I'll review your code, but I want to decide this issue before we publish a new version. Thanks! Jordan Wilberding On Wed, Feb 9, 2011 at 11:52 PM, Martin Logan <[email protected]>wrote: > I have updated pmaps for exceptions. I actually ended up useing the > second approach of adding a return class to results to differentiate > exceptions and normal flow so the code is different from yesterday. > You can find this code in the master of my repo. It should now be a > fast forward from the erlware/master head. There is something else I > want to bring up in terms of the design of this module. > > The module currently handles timeout in two conflicting manners. In > map a timeout is returned in the final mapped list as if it were > application level. Filter, it treats timeout like false and excludes > it from the returned list; which is not congruent with how map treats > it. Why not treat timeout like true and include timeout in the list as > further application level results like in map? The choice is not > consistent in this module currently. > > If a process does not return a value perhaps it should be excluded > from the results of map. A map presumes a map across all elements. If > one does not work adding in 'timeout' as a substitute is not strictly > correct. In any case it appears to me that there are two modes that > seem correct: > > 1. asyncronous, excluding timeout and not treating it as an > application level return value > 2. atomic/syncronous such that all operations/processes must succeed > in that they return an application level result or the whole plist > operation fails. > > I will admit that having the timeouts is valuable but returning them > simply as timeout, when that could actually be an valid return value > from a process that does not timeout is not good practice. At the > least, given erlangs lack of types which hurts in this case, returning > something obscure like gen_server:cast does underneath makes sense; > something like '$timeout$' as ugly as that is. > > Cheers, > Martin > > > -- > Martin Logan > Erlang & OTP in Action (Manning) http://manning.com/logan > http://twitter.com/martinjlogan > http://erlware.org > > -- > You received this message because you are subscribed to the Google Groups > "erlware-dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
