F # MailboxProcessor aka Agent come API

3

Visto che c'è un aumento nelle soluzioni basate su attori, sono un po 'confuso riguardo alla mancanza di lib di F # che usano qualcosa come il MailboxProcessor come API.

Qual è il lato negativo?

Perché gestire le capacità limitate e il sovraccarico dei wrapper?

Esistono API F # che utilizzano un agente come API di prima classe invece dei dettagli di implementazione?

Sto parlando della concorrenza non bloccante con gli desiderati scenari di effetti collaterali. Soprattutto i casi in cui una lib usa già qualcosa come MailboxProcessor sotto il cofano, ma definisce i wrapper attorno al protocollo di comunicazione (che potrebbe essere ben definito con DU).

Immagino che il messaggio che passa in alto sia nell'occhio di chi guarda, ma penso che Erlang e Scala dimostrino che il funzionale va di pari passo con gli attori. Esistono anche implementazioni Haskell, quindi non è una questione di purezza, ma piuttosto di stile.

Quando dico che i wrapper sono vincolati, intendo:

  • duplicazione del protocollo (wrapper + messaggistica sottostante). Va bene se tutto ciò che esponi è un metodo, ma spesso non lo è.

  • duplicazione esplicita delle funzionalità (fire-and-forget, async con risultato, sincronizzazione, ecc.). Coprendo ogni possibilità con un wrapper risulterebbe un'API inutilmente gonfia, mentre non coprendola - in realtà rimuoverà la capacità.

  • set di verbi non standard, che riduce la capacità di comporre.

Supponendo che non siate contrari agli attori in linea di principio, quali sono i lati negativi dell'utilizzo di MailboxProcessor come API standard per implementazioni che coinvolgono la concorrenza non bloccante?

    
posta Eugene Tolmachev 09.06.2015 - 21:13
fonte

1 risposta

3

Il F # MailboxProcessor è essenzialmente una coda in memoria di fronte a un loop a thread singolo. Mentre questo rende sicuramente più semplice programmare i sistemi "concorrenti" che devono manipolare lo stato , ha i seguenti svantaggi:

  • Viene eseguito solo su un singolo thread
  • Sovraccarico dalla sincronizzazione

Il modello di attore è un approccio sano alla programmazione di stato. Quando ne hai bisogno, è molto preferibile agli approcci che riguardano thread e lock.

F #, tuttavia, è un linguaggio di programmazione Functional First e la maggior parte delle librerie F # che ho incontrato prendono sul serio. Esse enfatizzano le query a effetto collaterale rispetto alla programmazione stateful, che spesso rendono le loro API imbarazzanti parallelamente . Quando hai qualcosa di imbarazzantemente parallelo, non c'è motivo di metterlo su un singolo thread.

    
risposta data 10.06.2015 - 07:38
fonte

Leggi altre domande sui tag