Funzionalità di esternalizzazione dalla vista Django a C / C ++

Question

Funzionalità di esternalizzazione dalla vista Django a C / C ++

#1 da (3 voti)

2

Sto sviluppando un progetto Django che fondamentalmente si riduce a:

Un utente invia un modulo.
La vista Django analizza il modulo e compila una rappresentazione di quella forma che è leggibile da qualche altra 'funzione'. Per "funzione", intendo un qualche tipo di eseguibile / chiamabile in cui la vista di Django può essere agnostica su quale lingua sia stata scritta la "funzione" o anche su quale hardware viene eseguito.
La vista Django passa il modulo compilato nella 'funzione'.
La "funzione" svolge la propria attività sull'input, quindi restituisce alcuni dati in un formato leggibile dalla vista Django.
La vista Django legge l'output della 'funzione' e rende i dati in un formato che è consumabile dall'utente.

Nel mio caso specifico, la 'funzione' è un grande calcolo numerico non adatto per plain-vanilla Python. Inoltre, questa 'funzione' è già stata sviluppata in C ++ 11 e Python può dialogare con il binario compilato via os.system e file IO.

La mia domanda è: perché non dovrei usare solo os.system o sottoprocesso dalla vista Django piuttosto che

a) ridisegna la 'funzione' usando uno dei tipi | sorso | Boost.Python | pyrex | Cython ;

b) scopri come scrivere estensioni Python e riscrivere la "funzione" di conseguenza ?

Ho anche pensato di trasformare la 'funzione' in un daemon, ma non ho abbastanza esperienza con i daemon per poter valutare quali sarebbero le conseguenze di un tale progetto.

Ci sono comportamenti indesiderati / non definiti che potrebbero derivare dall'uso di os.system / sottoprocesso come descritto sopra per un progetto Django che stava funzionando sotto carico?

C'è qualcos'altro che mi manca è super ovvio per tutti gli altri?

C'è anche questa domanda correlata . Ma con la scarsità di dettagli sia nel caso d'uso dell'OP che nelle risposte, sono prudente a non cadere per il mio fallace bias di conferma.

django

posta user0xf00 17.07.2014 - 08:39

fonte

1 risposta

Leggi altre domande sui tag django

Kerberos per la gestione delle chiavi? Differenza tra arrotondamento USP e IEEE

score 3 · Accepted Answer

Non c'è nulla di spregiudicato nel chiamare una routine di libreria scritta in una lingua da un'applicazione scritta in un'altra lingua. Succede tutto il tempo. Un buon esempio è il codice SQL incorporato nella maggior parte degli altri linguaggi.

I problemi con cui lo fai è semplicemente skillset, per mantenere questa funzione esterna devi conoscere sia C ++ che python.

Come dici tu, hai molte opzioni per interfacciarti a questo. Vorrei raccomandare un meccanismo di tipo ctypes in quanto sarà l'overhead più basso, che è quasi l'unica considerazione a meno che non sia possibile ricostruire la funzione in una libreria condivisa. Far funzionare le chiamate di sistema a un processo esterno, è molto più lento per ottenere dati da e verso un processo piuttosto che passarlo a una libreria condivisa caricata in-process. È possibile convertire la funzione in un servizio Web e chiamarla utilizzando le chiamate SOAP o REST, ad esempio.

Un daemon è solo un processo in esecuzione che è costantemente in esecuzione. È più veloce della semplice esecuzione della funzione su richiesta, in quanto il sistema operativo non deve impiegare tutto il tempo necessario per avviare il processo ogni volta che si desidera chiamare una funzione. Per convertirlo in un demone potresti dover modificare il codice da eseguire quando più applicazioni chiamano la funzione simultaneamente, ma altrimenti non è diversa.

Quindi: se la velocità di chiamare la funzione in un processo non è importante (ad es. è una funzione intermittente o di lunga durata), andare avanti e chiamarla utilizzando le chiamate di sistema. Ma, se hai bisogno di velocità, e questa funzione ritorna velocemente, o viene chiamata più volte, allora penso che dovresti imparare come i programmi C / C ++ sono scritti e costruiti. Quindi avrai le competenze per trasformarlo in una biblioteca e chiamarlo usando i ctype.