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

Plus de threads au toplevel? #3298

Closed
vicuna opened this issue Apr 14, 2002 · 5 comments
Closed

Plus de threads au toplevel? #3298

vicuna opened this issue Apr 14, 2002 · 5 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Apr 14, 2002

Original bug ID: 1097
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour,

Les threads ne semblent plus marcher au toplevel:

$ ocaml -I +threads
Objective Caml version 3.04+9 (2002-04-04)

#load"unix.cma";;

#load"threads.cma";;

[ hang ]
^CInterrupted.

Segmentation fault (core dumped)

Teste' sur FreeBSD 4.5, -posix-thread.

Jacques Garrigue

@vicuna
Copy link
Author

vicuna commented Apr 15, 2002

Comment author: administrator

Les threads ne semblent plus marcher au toplevel:

$ ocaml -I +threads
Objective Caml version 3.04+9 (2002-04-04)

#load"unix.cma";;

#load"threads.cma";;

[ hang ]
^CInterrupted.

Segmentation fault (core dumped)

Je n'ai pas pu reproduire le problème sous Linux, mais je crois qu'un
utilisateur l'a signalé sous Windows. Je vais regarder de plus près.

Mais de manière générale, #load "threads.cma" au toplevel n'est pas
conseillé, car avec les threads bytecode, ça ne marche pas du tout (le
toplevel est linké avec la version non-threadée de la bibliothèque
standard, d'où arrêt immédiat sur une exception Sys_io_blocked).

Mieux vaut donc faire "ocamlmktop -thread threads.cma". Il faudra
documenter cela dans le manuel.

D'ailleurs, si tu fais "ocamlmktop -thread threads.cma", est-ce que le
plantage persiste?

  • Xavier

@vicuna
Copy link
Author

vicuna commented Apr 15, 2002

Comment author: administrator

Ou bien utiliser -with-pthread par defaut, car ca a en plus l'avantage
de permettre le chargement dynamique de bibliotheques C qui ont besoin
des pthreads (la libGL.so de XFree 4 par exemple).
Les threads posix ont ils des inconvenients?

Oui, deux:

  • implémentations plus ou moins stables suivant les systèmes...
  • plus lourdes que les threads bytecode en terme de mémoire utilisée,
    de coût de création de thread, et de nombre maximal de thread supporté.

Le second point pourrait être réglé par une implémentation à deux niveaux
(threads systèmes mutiplexant l'exécution de threads bytecode), mais
c'est un gros boulot d'implémentation...

  • Xavier

@vicuna
Copy link
Author

vicuna commented Apr 15, 2002

Comment author: administrator

FreeBSD problem went away by recompilation. Windows problem fixed 2002-04-15 by
XL.

@vicuna vicuna closed this as completed Apr 15, 2002
@vicuna
Copy link
Author

vicuna commented Apr 15, 2002

Comment author: administrator

From: Xavier Leroy xavier.leroy@inria.fr

Je n'ai pas pu reproduire le problème sous Linux, mais je crois qu'un
utilisateur l'a signalé sous Windows. Je vais regarder de plus près.

C'est-y-pas moi? Ocamlbrowser ne marche pas sur Windows, et ca semble
etre lie' aux threads.

Mieux vaut donc faire "ocamlmktop -thread threads.cma". Il faudra
documenter cela dans le manuel.

Ou bien utiliser -with-pthread par defaut, car ca a en plus l'avantage
de permettre le chargement dynamique de bibliotheques C qui ont besoin
des pthreads (la libGL.so de XFree 4 par exemple).
Les threads posix ont ils des inconvenients?

D'ailleurs, si tu fais "ocamlmktop -thread threads.cma", est-ce que le
plantage persiste?

Oui, c'est pour ca que j'ai fait un rapport (oubliant de
l'indiquer...)
Mais j'ai du mal a reproduire. Y compris sur une autre machine avec FreeBSD. Je t'envoie plus de detail s'y j'arrive a reproduire, sinon
il s'agit juste d'un phenomene bizarre.

Jacques

@vicuna
Copy link
Author

vicuna commented Apr 15, 2002

Comment author: administrator

D'abord, je confirme qu'on peut fermer ce rapport errone' de ma part:
apres moult verifications, le probleme semble venir de ce que j'avais
oublie' de refaire configure apres l'introduction des operations
64-bits.

From: Xavier Leroy xavier.leroy@inria.fr

Ou bien utiliser -with-pthread par defaut, car ca a en plus l'avantage
de permettre le chargement dynamique de bibliotheques C qui ont besoin
des pthreads (la libGL.so de XFree 4 par exemple).
Les threads posix ont ils des inconvenients?

Oui, deux:

  • implémentations plus ou moins stables suivant les systèmes...
  • plus lourdes que les threads bytecode en terme de mémoire utilisée,
    de coût de création de thread, et de nombre maximal de thread supporté.

Le second point pourrait être réglé par une implémentation à deux niveaux
(threads systèmes mutiplexant l'exécution de threads bytecode), mais
c'est un gros boulot d'implémentation...

Est-ce qu'il serait possible d'avoir un mecanisme permettant
d'installer les deux versions ensembles?
Je comprends maintenant qu'elles ont chacunes leurs avantages propres,
mais comme elles ne sont pas 100% compatibles au niveau du
comportement, ca complique la distribution de programmes.

Amicalement,

Jacques

@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant