Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signals and ocamlopt #3166

Closed
vicuna opened this issue Sep 10, 2004 · 3 comments
Closed

signals and ocamlopt #3166

vicuna opened this issue Sep 10, 2004 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Sep 10, 2004

Original bug ID: 3166
Reporter: administrator
Status: closed (set by @mshinwell on 2016-12-08T13:17:16Z)
Resolution: not a bug
Priority: low
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

D'apres le manuel d'ocamlopt:

Signals are detected only when the program performs an allocation in
the heap. That is, if a signal is delivered while in a piece of code
that does not allocate, its handler will not be called until the next
heap allocation.

Ca me parait completement faux: on attend en general le prochain appel
de caml_garbage_collection, qui ne se produit que lorsque le tas jeune
est plein. Ca peut demander un certain nombre d'allocations
successives.

De plus, tous les appels au GC ne passent pas par
caml_garbage_collection. En particulier, Alloc_small/caml_alloc_small
declenche le GC sans passer par la, et est utilise' par toutes les fonctions C, y compris l'allocation des arrays. D'ou la situation bizarre dans laquelle je me suis trouve' avec un
petit interprete compile' avec ocamlopt: il allouait a` tours de bras,
mais uniquement via Array.create et Obj.new_block. Par consequent,
caml_garbage_collection n'etait jamais appele', et les signaux
joyeusement ignores.

Il faudrait au moins corriger le manuel, et ca serait bien d'avoir un
moyen de traiter le cas ci-dessus. Je m'en suis sorti en allouant des
listes a` un element partout ou ca risque de boucler, mais c'est un peu
acrobatique.

Jacques

@vicuna
Copy link
Author

vicuna commented Nov 3, 2004

Comment author: administrator

D'apres le manuel d'ocamlopt:

Signals are detected only when the program performs an allocation in
the heap. That is, if a signal is delivered while in a piece of code
that does not allocate, its handler will not be called until the next
heap allocation.

Ca me parait completement faux: on attend en general le prochain appel
de caml_garbage_collection, qui ne se produit que lorsque le tas jeune
est plein. Ca peut demander un certain nombre d'allocations
successives.

Non, car le signal handler modifie caml_young_limit de telle manière
que la prochaine allocation dans le tas mineur va échouer et appeler
caml_garbage_collection(), lequel va traiter le signal.

Enfin, ça c'est la théorie. En pratique on a deux problèmes. Le
premier est que dans certains portages, caml_young_limit est "caché"
dans un registre du processeur, et suivant la combinaison
OS/processeur, le signal handler peut ou non mettre à jour ce cache de
caml_young_limit.

Le second problème est, comme tu l'as remarqué:

De plus, tous les appels au GC ne passent pas par
caml_garbage_collection. En particulier, Alloc_small/caml_alloc_small
declenche le GC sans passer par la`, et est utilise' par toutes les
fonctions C, y compris l'allocation des arrays.

Il y a un commentaire dans asmrun/signals.c qui explique cela:

/* This routine is the common entry point for garbage collection
and signal handling. It can trigger a callback to Caml code.
With system threads, this callback can cause a context switch.
Hence [caml_garbage_collection] must not be called from regular C code
(e.g. the [caml_alloc] function) because the context of the call
(e.g. [intern_val]) may not allow context switching.
Only generated assembly code can call [caml_garbage_collection],
via the caml_call_gc assembly stubs. */

Je ne sais pas si ce commentaire est toujours d'actualité. En
particulier il faudrait regarder intern_val à la loupe pour voir si
vraiment ça peut faire un GC mais pas de context switch.

Amitiés,

  • Xavier

@vicuna
Copy link
Author

vicuna commented Nov 6, 2004

Comment author: administrator

TODO: check whether it is still true that allocations performed in C must not
handle signals.

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

The only part outstanding from all those years ago is the question about the comment.

I had a quick look at that and as far as I can see the comment is still accurate. The function caml_input_val_core initialises some global state (in [intern_init]) before calling [intern_alloc] which allocates on the OCaml heap. If a context switch were to occur at that point, the global variables initialised by [intern_init] might become clobbered by a concurrent demarshalling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant