this is what I am advocating as well. I think there can be a pmap/4 that takes the option to not fail.
On Thu, Feb 10, 2011 at 7:03 AM, Jordan Wilberding <[email protected]> wrote: > 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. > -- 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.
