On Wed, Feb 9, 2011 at 8:26 AM, Eric Merritt <[email protected]> wrote:
> I agree with you at the higher level. That exceptions need to be
> distinguishable from non-exception errors. I am not a big fan o this
> syntax though.
>
> In this we have two levels which are passing information back. The
> pmap level and the thing that is being pmapped. Both can return
> values. However, I don't think the pmap level should rely on the lower
> level to map its values. So we should have this return protocol at the
> pmap level
>
> {ok, _}
> {error, ErrorType, _}
> {exception, ExceptionType, StackInformation}
>
> I don't think we need a special atom for the exception at all. Its
> location gives it the extra specialness it needs.
We do need the special syntax because the current return message in
do_f is of the form
{Self::pid(), Result::term()}
Where Result is user defined application level data. This means that
anything can come back from it and we need a way to distinguish
between application level data and lower level signals like type
information around exceptions. This means we can do one of two things,
enhance the protocol to look like
{Self::pid(), {Type::atom(), Result::term()}}
which means I need to change the protocol throughout in all cases in
the current code. The other thing I can do is similar to what is done
in gen_server.erl with the cast function in order to distinguish casts
from those messages that come in out of band and should be handled by
handle_info. Either approach is valid and has its minor plusses and
minuses.
As for the rest of your message, call me, I am not sure what you are
trying to say honestly.
Cheers,
Martin
>
> Now realize that this is at the pmap level. If the lower level returns
> on error, but pmap is happy could could end up with something like
>
> {ok, {error, _}}
>
> where error is just the return value from the pmapped function.
>
> This is different then lists:map because lists:map run in the same
> process space as the caller and in serial. An exception lists:map
> behaves as expected, that is it stops all processes and does a non
> local exit. There for lists:map can just directly return the value
> from the called function. Our pmap can not, for the reasons described
> here.
>
> I hope this makes some sense.
>
>
>
>
>
>
> On Tue, Feb 8, 2011 at 9:12 PM, Martin Logan <[email protected]> wrote:
>> Guys, pmap needs to pass through exceptions. The implementation will
>> be fairly straightforward, anyone against this?
>>
>> In the do_f function we have the line. I would change this line to
>> something like
>>
>>
>> Parent ! {self(), {error, ErrType, Error}}
>>
>>
>> Parent ! {self(), {'$exception$', ErrType, Error}}
>>
>> This would be to sufficiently distinguish an exception from a passed
>> back error. Right now we autoconvert exceptions into errors which does
>> not look quite correct to me. There may be caveats to passing back the
>> exception though and that is what I am asking you to think on. Anyhow,
>> If this response above comes back into
>>
>> wait(Parent, Child, Timeout) ->
>> receive
>> {Child, Ret} ->
>> Parent ! {self(), Ret}
>>
>> which would then be recognized there and passed back to Parent. When
>> Parent receives an exception message it would rethrow it. Anyone
>> wishing to collect all responses would need to catch exceptions at an
>> application level. Exceptions would serve to short circuit the
>> execution of any map functions in this way.
>>
>> 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.
