CCR: best practice per la gestione degli errori utilizzando le causalità

Question

Avere una sequenza complessa di attività, implementare la gestione degli errori può rapidamente gonfiare il codice quando si utilizzano i blocchi try/catch e roba come i ricevitori Choice su PortSet<ActualResult, Exception> per ogni piccola attività.

Fortunatamente il CCR sembra offrire un meccanismo per gestire le eccezioni in un modo più generale per un grafico delle attività: causalità. Un esempio tipico è simile al seguente:

Port<Exception> exceptionPort = new Port<Exception>(); 
Dispatcher.AddCausality(new Causality("some job", exceptionPort)); 
Arbiter.Activate(
    dispatcherQueue, 
    Arbiter.Receive(false, exceptionPort, ex => Console.WriteLine(ex))); 
// now schedule the real tasks 

Nel mio caso, ho un applicazione intensiva di calcolo utilizzando il CCR per implementare uno scatter/gather scenario, la divisione "lavori" in un mucchio di compiti parallelizzati. (Oltre a questo, più di uno di questi lavori può essere eseguito allo stesso tempo.) Nel caso in cui un'attività fallisca, voglio interrompere tutte le attività rimanenti nel lavoro, ma non qualsiasi altro lavoro. (I risultati non mi sono utili se mi manca un pezzo del puzzle, quindi continuare a lavorare su questo sarebbe solo uno spreco di tempo CPU.)

La domanda è quale sarebbe il modo migliore per attuare l'arresto.

Un'idea potrebbe essere:

1. Creare un unico Dispatcher istanza e tenerlo durante la vita dell'applicazione.
2. Creare un nuovo DispatcherQueue per ogni "lavoro" (un gruppo di attività). Aggiungere Causality subito dopo aver creato lo DispatcherQueue.
3. Nel gestore per la coda di eccezione, chiamare Suspend() su DispatcherQueue.
4. Prima di smaltire la coda del dispatcher, rimuovere la causalità.

Mi chiedo se questo suggerimento possa essere considerato una buona pratica, o se c'è un approccio migliore per affrontare uno scenario simile - probabilmente abbastanza comune.

Answer 1

Sembra un buon modo per andare avanti a parlarmene.