[dmd-concurrency] draft 6

[Andrei Alexandrescu]

Michel Fortin wrote:
> Le 2010-01-28 à 11:18, Andrei Alexandrescu a écrit :
> 
>> Heh. Good point. I should rephrase that. The point is that 
>> sometimes you call receive() without a Variant handler because you 
>> want to leave non-matching messages in the mailbox, in knowledge 
>> that you'll handle them later. Here's the rephrase:
>> 
>> ========= Planting a\sbs @Variant@ handler at the bottom of the 
>> message handling food chain  is a good method  to make sure that 
>> stray messages aren't left in your mailbox. =========
> 
> Better.
> 
> But then I'll ask another question (I suspect the answer might expose
>  a problem): when do you want to handle messages immediately?

In many situations, e.g. when you want to dispatch them to other 
threads. But really the fact of the matter is, any given paragraph of 
the book cannot explain every single implication and every single 
ramification immediately. If I mention an explanation, then I'd most 
likely need to qualify it and further exemplify it etc.

>>>> If a thread exits via an exception, the exception OwnerFailed 
>>>> propagates to all of its owned threads by means of 
>>>> prioritySend.
>>> I though we were in agreement that it'd be better if this was 
>>> handled serially by default to avoid races in the program's 
>>> logic?
>> I think it's fine to propagate serially on _success_ but not on 
>> failure. Failure has priority.
> 
> I argued previously that this is what you want sometime, but not 
> always. If you were "copying" your file by sending its content to a 
> browser and a failure happens while reading the end of the file, 
> you'd want to continue sending the file up to the error point. On the
>  other side if you're copying to another file, you might want to 
> delete the partial copy in case of failure. In the later case, 
> sending the event faster is an optimization, in the first case, it is
>  not even desirable.

It's all a matter of defaults. You can choose to catch the exception and 
send it without priority.

>> ========= In this  case, @fileWriter@ returns  peacefully when 
>> @main@  exits and everyone's  happy.   But  what  happens  in  the 
>> case  the  secondary thread---the writer---throws  an exception? 
>> The call to  the @write@ function may fail if there's a  problem 
>> writing data to @tgt at . In that case, the call to @send@ from the 
>> primary thread will fail by throwing an\sbs   @OwnedFailed@ 
>> exception,  which   is  exactly   what  should happen. By the  way,
>>  if an owned thread exits  normally (as opposed to throwing an 
>> exception), subsequent calls to @send@ to that thread also fail, 
>> just with a different exception type:\sbs @OwnedTerminated at . 
>> =========
> 
> That only partially address my point. In the thread termination 
> protocol I wrote, if a thread terminates with an uncaught exception, 
> that exception is sent back to the owner thread (and you'd get it on 
> a call to receive). Have you decided not to do any of this?

I don't know. Erlang offers a different primitive spawn_link for 
explicitly making the parent receive exceptions from the child. The 
default is the parent doesn't care.


Andrei