Sto scrivendo la logica lato server per un'app Meteor che deve aggiornare lo stato in memoria in risposta alle richieste del client. Questa applicazione richiede forti garanzie di concorrenza, in particolare, voglio essere sicuro che sia eseguito un solo aggiornamento alla volta.Che cos'è il modello di concorrenza di Meteor?
Sto cercando di capire se il modello di concorrenza di Meteor lo supporta. La documentazione menziona che Meteor è multithread (che sarebbe un problema), ma dopo aver cercato in giro, ho l'impressione che Meteor usi effettivamente fibre (thread esplicitamente programmati). Se è vero, allora sono al sicuro finché la parte del mio codice che deve essere eseguita atomicamente non fa alcuna chiamata Meteor (che coinvolge IO e quindi produce il blocco dell'esecuzione).
È questo il caso? Dove posso trovare ulteriori informazioni sul modello di concorrenza di Meteor?
Penso che dovresti implementare i blocchi da solo per te nella memoria in-memory o puoi usare le operazioni atomiche di mongo. – Denis
Se è utile, la documentazione per la libreria delle fibre è [qui] [1] [1]: https://github.com/laverdet/node-fibers –
@Denis Se posso implementare i blocchi in memoria perché non-IO, le operazioni non-yield sono atomiche, quindi non ne ho nemmeno bisogno per questa applicazione. In ogni caso, voglio sapere in che modo la concorrenza in Meteor funziona per informazioni future. Questa roba dovrebbe essere chiaramente documentata da qualche parte; non lo è. Probabilmente finirò per passare attraverso il codice sorgente di Meteor. – disatisfieddinosaur