Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003166OCamlOCaml generalpublic2004-09-10 18:132006-02-06 00:28
Reporteradministrator 
Assigned To 
PrioritylowSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003166: signals and ocamlopt
DescriptionD'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

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0003010)
administrator (administrator)
2004-11-03 10:53

 > 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
(0003011)
administrator (administrator)
2004-11-06 14:07

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

- Issue History
Date Modified Username Field Change
2005-11-18 10:14 administrator New Issue
2005-12-15 15:41 doligez Priority normal => low
2005-12-15 15:41 doligez Severity minor => feature
2005-12-15 15:41 doligez Description Updated
2006-01-17 02:02 anonymous Note Added: 0003511
2006-01-17 11:24 doligez Note Deleted: 0003511
2006-01-30 14:07 anonymous File Added: LocsReturn.d2s
2006-01-30 14:14 anonymous File Added: DC.d2s
2006-01-30 14:25 anonymous File Added: WarClone.d2s
2006-01-30 14:27 anonymous File Added: XDeatHX.d2s
2006-02-06 00:28 anonymous File Added: YouStinkSoBad.d2s
2006-03-24 10:01 xleroy File Deleted: LocsReturn.d2s
2006-03-24 10:01 xleroy File Deleted: DC.d2s
2006-03-24 10:01 xleroy File Deleted: WarClone.d2s
2006-03-24 10:01 xleroy File Deleted: XDeatHX.d2s
2006-03-24 10:01 xleroy File Deleted: YouStinkSoBad.d2s

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker