stop et ifactor

[frederic han]

Salut,

en 0.9.1, si l'on interrompt ifactor avec le bouton stop

apres il ne veut plus recommencer ni tout ce qui depend de pari.

N:=nextprime(10^30)*nextprime(33*11^20)
ifactor(N)

puis bouton stop

alors
le ifactor suivant donne:

PARI locked by another thread. Try again later Error: Bad Argument Value

idem pour pari()

Fred

[alb]

Même remarque avec:
ifactor(3430!) qui ferme xcas et
ifactor(3500!) qui renvoie Error in PARI subsystem Error: Bad Argument Value (petit air de déjà vu)
Obligé de relancer pour continuer.

[parisse]

Je ne sais pas corriger ça: la raison c'est que le bouton STOP tue le thread de calcul, mais comme PARI n'est pas réentrant, il y a un verrou (un pthread_mutex_t) mis en place au lancement du calcul pour éviter que 2 process de calculs (de 2 sessions différentes) accèdent à PARI en même temps. Et en tuant le thread, on laisse le verrou. Il faudrait éliminer le verrou à la fermeture du thread.

[frederic han]

Pour ifactor(3500!) ca a l'air d'etre un peu different:

(chez moi 3430! fonctionne) mais pour 3500!
il me donne:
*** the PARI stack overflows !
current stack size: 10000000 (9.537 Mbytes)
[hint] you can increase GP stack with allocatemem()

en revanche avec le veritable pari ca a l'air de fonctionner.

de plus sous xcas il y a quelques differences:
pari()
pari(6!)
donne: 7.2000000000e+02 alors que sous pari on a 720


pari_factor(3500!) ne bloque pas xcas mais retourne:
[[poly1[1,0],1]]

N:=nextprime(11^30)*nextprime(33*11^30)
pari_factor(N) donne immediatement
[[10047894104866797285956826746916804517477645993578996952062786959,1]]
alors que ifactor(N) et le vrai pari essayent de le faire.


Y a t'il une possibilite d'avoir une fonction qui delocke pari avec un warning pour les calculs similtanes? Eventuellement une fenetre posant la question lorsque l'on a l'erreur:
PARI locked by another thread. Try again later Error: Bad Argument Value

la meme pari() n'y fait rien, ni restart.

Fred

[parisse]

Salut!

je suppose que gp doit augmenter tout seul la taille de la pile, ce que ne fait pas xcas (il faudrait que je catche l'erreur de pile de pari, ca doit etre faisable mais il faut y regarder de pres).
Pour le verrou sur le thread, il est peut-etre possible de le supprimer en rajoutant des fonctions à exécuter à l'expiration du thread.
Je regarderai ca et les différences que tu soulèves si j'ai le temps la semaine prochaine...
a+

[parisse]

Bon, apres examen de la situation, une bonne et une mauvaise nouvelle:
la bonne c'est que les problemes avec ! devraient etre corriges, c'est parce que xcas imprimait arg! en factorial(arg) au lieu de arg! et que pari interprete factorial en approche.
la mauvaise c'est que pour les thread locked, j'avais deja essaye de faire un appel a la fonction de deverrouillage, c'est le role du pthread_cleanup_push(pari_cleanup, (void *) &pari_mutex); dans par exemple pari_isprime, pari_ifactor, mais apparamment ca ne marche pas

[frederic han]

Et en attendant d'avoir mieux, si j'ai bien compris le test

if (locked)

ne sert que dans le mode ou l'on a mis dans la config plusieurs threads non?

serait il possible de tester si la variable threads dans le menu xcas est a 1 et ne pas faire les tests if(locked) dans ce cas?

Fred

[parisse]

Pas seulement, ca sert aussi si tu as plusieurs tabs dans une meme session.

[frederic han]

J'ai fait un essai pour voir si une commande a executer manuellement pourrait marcher.

J'ai commente le test if (locked) dans isprime afin de pouvoir l'executer tout de meme en esperant que la fin fera le menage.

alors si je lance un gros ifactor et que je l'interompt avec le bouton stop, toutes les commandes pari sont bloquees, mais elles se debloquent bien apres l'execution de ce isprime traffiqué.

Sans cela je n'ai pas d'autre moyen que de quitter xcas et de le relancer , est ce que tu penses que de faire une fonction a executer manuellement pari_unlock serait un depannage possible? Par exemple le message d'erreur pourrait mentionner cette possibilite?

Fred

[parisse]

Tu as raison, il faut rajouter la possibilite de forcer le remplacement du mutex. Je vais reflechir a comment implementer cela.

[parisse]

Bon, finalement ce n'était pas très difficile, ça devrait marcher avec le source à jour (et le package linux de testing)!

[frederic han]

Oui ca marche pour le Pb de lock.

J'ai MAJ xcas_user

Fred