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

Bug description

Bonjour,

Xavier Leroy [Fri, 11 Jun 2004]:

Ben, ça désactive complètement la préemption entre threads Caml,
donc c'est un peu violent!

hum, oui il faut libérer le lock de temps en temps ...

Moins violent: dans otherlibs/systhreads/posix.c, supprimer l'appel à
sched_yield() dans caml_thread_yield(). Ça m'intéresserait de savoir
comment se comporte le noyau 2.6 après cette modif lorsqu'on a
plusieurs threads Caml qui calculent beaucoup (p.ex. l'exemple de
Christophe avec 2 threads qui font compute(), ou plus). Est-ce que le
scheduling entre ces threads reste équitable?

J'ai essayé ce programme:
,----
| let compute pref =
| let i = ref 0 in
| while true do
| incr i;
| if !i mod 1000000 = 0
| then Printf.printf "%s: %d\n%!" pref !i
| done
|
| let _ = Thread.create compute "thread 1"
| let _ = Thread.create compute "thread 2"
| let _ = compute "main thread"
`----
en commentant dans posix.c l'appel à sched_yield(). Ça marche
correctement, les 3 threads travaillent. Mais ça marche aussi bien en
laissant le sched_yield :). Ça serait donc le thread interface(),
bloquant sur un read qui poserait problème (?).

J'ai remarqué autre chose: en lançant en arrière plan le programme
avec interface(), le programme est stoppé (c'est normal puisqu'il
essaye de lire sur stdin) mais j'obtiens aussi:
'Thread 1 killed on uncaught exception Sys_error("Unknown error 512")'

Le thread n'est pas killé avec Linux 2.4.

--
Olivier