Problemi con Erlang NIF e thread

Question

Ho un piccolo problema con i thread nei NIF di Erlang. È possibile visualizzare il mio codice qui: http://pastebin.com/HMCj24Jp. Il problema è che quando avvio il thread ci vogliono alcuni argomenti e avvia la funzione generate_binary. Va bene, ma quando sto cercando di leggere gli argomenti, tutto si blocca.

Forse non è il problema più complesso, ma non sono riuscito a trovare alcuna documentazione su questo, quindi spero che alcuni di voi possano conoscere la risposta.

Answer 1

Il generate_buffer() Il NIF sta creando una discussione per chiamare generate_binary() ma il NIF di chiamata non attende il completamento del thread appena creato. Il thread viene appena creato e probabilmente è ancora in esecuzione al momento del ritorno del NIF, anche se questo sarà non deterministico, in quanto i thread sono in generale. Probabilmente stai bloccando l'emulatore di ERLang BEAM perché generate_binary() è spento cercando di chiamare nel sistema di runtime Erlang dopo che generate_buffer() è tornato, confondendo la cosa povera in modo orribile.

Ora, anche supponendo che lo aggiusti per farlo fare ciò che volevi, non penso che dovresti usare esplicitamente i thread nativi qui.

In primo luogo, i NIF di Erlang dovrebbero assomigliare alle normali funzioni di Erlang, che differiscono solo per il fatto che sono scritte in una lingua diversa. Le funzioni di Erlang non generano thread di esecuzione separati, quindi restituiscono, lasciando in esecuzione quel thread. Ad eccezione di quelli che si occupano di I/O e memorizzazione persistente dei dati, le funzioni di Erlang sono deterministiche e referentially transparent. Il tuo NIF non è né Quindi, anche se ha funzionato, è ancora "sbagliato" nel senso che viola le aspettative di un programmatore esperto di Erlang.

In secondo luogo, se è necessario il multiprocessing, Erlang fornisce già l'idea dei processi. Se il tuo NIF farà davvero così tanto lavoro da trarre beneficio dal multiprocessing, perché non rileggere il tuo NIF in modo che possa lavorare su un subrange dei dati, quindi chiamarlo più volte, una volta ciascuno da un numero di processi di Erlang? Quindi non hai bisogno di espliciti thread nativi; l'emulatore BEAM creerà il numero ottimale di thread per te, in modo trasparente.

In terzo luogo, l'overhead per la creazione di thread sta per interrompere le prestazioni se la durata del thread si estende solo nel corso di una singola chiamata NIF di Erlang, come sembra proprio che si intenda. Questa è un'altra ragione per cui i processi di Erlang saranno più efficienti qui.