You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 3447 Reporter: administrator Status: closed Resolution: not a bug Priority: normal Severity: minor Category: ~DO NOT USE (was: OCaml general)
Bug description
Full_Name: Benjamin Leperchey
Version: 3.08
OS:
Submission from: cerium.pps.jussieu.fr (134.157.168.58)
Bonjour,
je suis en train d'ecrire un binding pour quelques fonctions de la librairie
SDL. J'ai rencontre un probleme pour les fonctions de son, qui fonctionnent par
callbacks: une interruption est generee quand le buffer est vide, il faut alors
le remplir. Evidemment, si on appelle directement une fonction Caml, le
programme crashe assez vite, puisqu'il se pourrait qu'on soit en pleine garbage
collection. J'ai resolu mon probleme en utilisant une variable globale en C, que
je mets a 1 quand il faut remplir le buffer, et que je scrute dans mon programme
Caml, mais
je perds tout le confort des callbacks,
dans mon cas, il faut que je retourne immediatement un buffer rempli, ce qui
m'oblige a utiliser un deuxieme buffer, rempli par Caml et recopie lors des
interruptions. A la cle, latence et grosse consommation de memoire et de CPU.
Je voudrais donc plutot pouvoir faire un test, executer la fonction directement
si c'est possible, et faire un appel asynchrone sinon. Apres examen du code du
runtime Caml, j'ai constate qu'il y avait plusieurs variables qui implementaient
des choses similaires: dans asmrun/signals.c, je lis
/* We can't execute the signal code immediately.
Instead, we remember the signal and play with the allocation limit
so that the next allocation will trigger a garbage collection. */
caml_pending_signal = sig;
caml_young_limit = caml_young_end;
ce qui est exactement ce que je voudrais faire, mais dans le cas particulier des
signaux unix. Dans byterun/signals.c, je vois
Full_Name: Benjamin Leperchey
Version: 3.08
OS:
Submission from: cerium.pps.jussieu.fr (134.157.168.58)
Bonjour,
je perds tout le confort des callbacks,
dans mon cas, il faut que je retourne immediatement un buffer rempli, ce
qui
m'oblige a utiliser un deuxieme buffer, rempli par Caml et recopie lors des
interruptions. A la cle, latence et grosse consommation de memoire et de CPU.
Grosse consommation, faut pas exagerer. C'est pas en recopiant 176 ko par
seconde que vous allez fatiguer un CPU moderne.
Je voudrais donc plutot pouvoir faire un test, executer la fonction
directement
si c'est possible, et faire un appel asynchrone sinon.
Ca n'est possible que dans un cas: si le programme est en train d'executer
une fonction C a forte latence et qui n'alloue pas, c'est-a-dire entre un appel
a caml_enter_blocking_section et le caml_leave_blocking_section suivant.
Si le signal arrive pendant l'execution d'un code Caml, c'est impossible.
Apres examen du code du
runtime Caml, j'ai constate qu'il y avait plusieurs variables qui
implementaient
des choses similaires: dans asmrun/signals.c, je lis
/* We can't execute the signal code immediately.
Instead, we remember the signal and play with the allocation limit
so that the next allocation will trigger a garbage collection. */
caml_pending_signal = sig;
caml_young_limit = caml_young_end;
ce qui est exactement ce que je voudrais faire, mais dans le cas particulier
des
signaux unix.
Je ne suis pas sur de comprendre. Ce code implemente justement une
synchronisation des signaux Unix, alors que vous voulez traiter des signaux
de maniere asynchrone.
qui m'a l'air tout a fait indiquee, mais je n'ai pas trouve de fonctions pour
y
acceder.
L'utilisation de cette variable est reservee a l'implementation des threads.
De
toutes facons, elle aussi, elle sert a synchroniser des signaux et pas a les
traiter de maniere asynchrone.
J'ai l'impression que la seule solution a votre probleme est d'utiliser un
double
buffer et un handler de signal ecrit en C qui recopie le buffer. Si vous
voulez
garder le confort des callbacks, il faut que votre handler C declenche un
handler
ecrit en Caml, en affectant caml_pending_signal et caml_something_to_do.
Original bug ID: 3447
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Bug description
Full_Name: Benjamin Leperchey
Version: 3.08
OS:
Submission from: cerium.pps.jussieu.fr (134.157.168.58)
Bonjour,
je suis en train d'ecrire un binding pour quelques fonctions de la librairie
SDL. J'ai rencontre un probleme pour les fonctions de son, qui fonctionnent par
callbacks: une interruption est generee quand le buffer est vide, il faut alors
le remplir. Evidemment, si on appelle directement une fonction Caml, le
programme crashe assez vite, puisqu'il se pourrait qu'on soit en pleine garbage
collection. J'ai resolu mon probleme en utilisant une variable globale en C, que
je mets a 1 quand il faut remplir le buffer, et que je scrute dans mon programme
Caml, mais
m'oblige a utiliser un deuxieme buffer, rempli par Caml et recopie lors des
interruptions. A la cle, latence et grosse consommation de memoire et de CPU.
Je voudrais donc plutot pouvoir faire un test, executer la fonction directement
si c'est possible, et faire un appel asynchrone sinon. Apres examen du code du
runtime Caml, j'ai constate qu'il y avait plusieurs variables qui implementaient
des choses similaires: dans asmrun/signals.c, je lis
ce qui est exactement ce que je voudrais faire, mais dans le cas particulier des
signaux unix. Dans byterun/signals.c, je vois
CAMLexport void (* volatile caml_async_action_hook)(void) = NULL;
qui m'a l'air tout a fait indiquee, mais je n'ai pas trouve de fonctions pour y
acceder.
Si effectivement il n'y en a pas, y aurait-il un empechement a en ajouter une?
Cordialement,
Benjamin
The text was updated successfully, but these errors were encountered: