Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#2376 Le 01/11/2012, à 16:07

tshirtman

Re : /* Topic des codeurs [7] */

En fait, j'ai réagis après, mais si tu enlève le -f, normalement, il écrase pas, sinon, les sources de python, tu les as, il ne les efface que quand tu relance, tu te mets dans build/python, tu cp fichier{,.orig} tu fait ton changement, et tu fait ton diff -u fichier{.orig,} > ../../recipes/python/patches/ton_patch.patch et ça devrait rouler.

smile

edit: sinon, pour mon probleme actuel, je pense que je peux gérer avec les threads python simples, au lieu de multiprocessing, donc si c'est trop galère, tant pis, mais si c'est possible, ce serait cool de l'avoir smile.

Dernière modification par tshirtman (Le 01/11/2012, à 16:08)

Hors ligne

#2377 Le 01/11/2012, à 16:10

Steap

Re : /* Topic des codeurs [7] */

@tshirtman: normalement, dans le config.log, t'as plus d'infos que juste "réussi/raté". Tu peux nous montrer la ligne de compilation ? Ca tombe, le test est compilé sans -lpthread, du coup la compilation échoue, et le test aussi.


GNU Guix, un gestionnaire de paquets fonctionnel.

Hors ligne

#2378 Le 01/11/2012, à 16:26

grim7reaper

Re : /* Topic des codeurs [7] */

Steap a écrit :

Ca tombe, le test est compilé sans -lpthread, du coup la compilation échoue, et le test aussi.

Ouais, mais dans ce cas le test raterait sur toutes les archi’ non ?
Ils auraient déjà eu un rapport de bug dans ce cas.

Cela dit, il semble bien y avoir des problèmes avec lpthread.

/home/grim7reaper/hacking/src/python-for-android/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin//../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: cannot find -lpthread

Dernière modification par grim7reaper (Le 01/11/2012, à 16:29)

Hors ligne

#2379 Le 01/11/2012, à 16:28

Steap

Re : /* Topic des codeurs [7] */

grim7reaper a écrit :
Steap a écrit :

Ca tombe, le test est compilé sans -lpthread, du coup la compilation échoue, et le test aussi.

Ouais, mais dans ce cas le test raterait sur toutes les archi’ non ?
Ils auraient déjà eu un rapport de bug dans ce cas.

Ca tombe il a un environnement un peu particulier, et le configure.ac ajoute pas "lpthread" dans les flags parce qu'on passe dans un chemin bizarre... Le plus simple est de vérifier si le flag y est, et de reproduire le problème en dehors du configure smile


GNU Guix, un gestionnaire de paquets fonctionnel.

Hors ligne

#2380 Le 01/11/2012, à 16:30

grim7reaper

Re : /* Topic des codeurs [7] */

J’ai édité, il y a bien un problème de lpthread.
Il ne le trouve pas.
Cela dit, ça semble normal car la libc d’Android n’en a pas besoin. Maintenant à voir si ça vient vraiment de là du coup, mais y’a sûrement un truc à patcher ouais.

Dernière modification par grim7reaper (Le 01/11/2012, à 16:31)

Hors ligne

#2381 Le 01/11/2012, à 17:02

grim7reaper

Re : /* Topic des codeurs [7] */

Ok, mon idée de base semble se confirmer.
Faut que je teste encore 2-3 trucs, mais d’abord il faut que j’aille faire les courses.



Édit : Bon pour expliquer l’idée en gros, le test de sem_getvalue rate car ils appellent sem_open dedans (c’était un peu mon idée de base).
Faudrait plutôt passer par sem_init, car sem_open semble pas implémenté sous Android.

Le test de configure.in :

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <semaphore.h>
#include <sys/stat.h>

int main(void){
    sem_t *a = sem_open("/autocftw", O_CREAT, S_IRUSR|S_IWUSR, 0);
    int count;
    int res;
    if(a==SEM_FAILED){
        perror("sem_open");
        return 1;

    }
    res = sem_getvalue(a, &count);
    sem_close(a);
    sem_unlink("/autocftw");
    return res==-1 ? 1 : 0;
}

Résultat (j’ai juste changé la compilation pour retirer -ldl et compiler en statique, sinon qemu me jette) :

android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -mandroid -fomit-frame-pointer --sysroot /home/grim7reaper/hacking/src/python-for-android/android-ndk-r7/platforms/android-14/arch-arm -o conftest -mandroid -fomit-frame-pointer --sysroot /home/grim7reaper/hacking/src/python-for-android/android-ndk-r7/platforms/android-14/arch-arm -static -lm conftest.c
qemu-arm conftest
sem_open: Function not implemented
echo $?
1

Test en utilisant sem_init :

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <semaphore.h>
#include <sys/stat.h>
#include <pthread.h>

int main(void){
    sem_t a;
    sem_init(&a, PTHREAD_PROCESS_PRIVATE, 0);
    int count;
    int res;
    res = sem_getvalue(&a, &count);
    return res==-1 ? 1 : 0;
}

Résultat :

android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -mandroid -fomit-frame-pointer --sysroot /home/grim7reaper/hacking/src/python-for-android/android-ndk-r7/platforms/android-14/arch-arm -o conftest -mandroid -fomit-frame-pointer --sysroot /home/grim7reaper/hacking/src/python-for-android/android-ndk-r7/platforms/android-14/arch-arm -static -lm conftest.c
qemu-arm conftest
echo $?
0

On a bien un code de sortie de 0.

Dernière modification par grim7reaper (Le 01/11/2012, à 17:11)

Hors ligne

#2382 Le 01/11/2012, à 17:11

tshirtman

Re : /* Topic des codeurs [7] */

si je trouve l'endroid ou il ajoute le -lpthread (y'a pleins de bon candidats dans configure.in) il suffirait que je le désactive?

Hors ligne

#2383 Le 01/11/2012, à 17:12

grim7reaper

Re : /* Topic des codeurs [7] */

Non je pense pas que ça soit un problème en soit : il rate le test du pthread au pire, mais le rester devrait tourner.
Le problème semble ailleurs (Cf. mon édit).

Hors ligne

#2385 Le 01/11/2012, à 17:21

Steap

Re : /* Topic des codeurs [7] */

Donc pthread est à motiié implémenté sur Android. Fantastique.


GNU Guix, un gestionnaire de paquets fonctionnel.

Hors ligne

#2386 Le 01/11/2012, à 17:26

tshirtman

Re : /* Topic des codeurs [7] */

Ah mais Python-2.7.2/Modules/_multiprocessing/semaphore.c utilise vraiment sem_open dans une macro, donc ça falloir l'adapter aussi, non?

 #define SEM_CREATE(name, val, max) sem_open(name, O_CREAT | O_EXCL, 0600, val)

et plus loin

handle = SEM_CREATE(buffer, value, maxvalue);

'tain ça fait longtemps que j'ai pas fait de C hmm

edit: j'avais pris la mauvaise macro

Dernière modification par tshirtman (Le 01/11/2012, à 17:28)

Hors ligne

#2387 Le 01/11/2012, à 18:27

grim7reaper

Re : /* Topic des codeurs [7] */

Steap a écrit :

Donc pthread est à motiié implémenté sur Android. Fantastique.

sem_open et d’autres n’existent pas sour Mac OS X il me semble.



tshirtman a écrit :

Ah mais Python-2.7.2/Modules/_multiprocessing/semaphore.c utilise vraiment sem_open dans une macro, donc ça falloir l'adapter aussi, non?

Bah du coup ouais.
Faut voir si c’est possible (à priori oui).
Au passage, faudrait voir s’ils y ont un jeux de tests pour multiprocessing, histoire de vérifier qu’on pète rien ^^

Édit : y’a un petit truc un peu piégeux, je vais voir ça après un bon repas.

Dernière modification par grim7reaper (Le 01/11/2012, à 18:35)

Hors ligne

#2388 Le 01/11/2012, à 18:58

tshirtman

Re : /* Topic des codeurs [7] */

#define SEM_CREATE(name, val, max) sem_init(val, PTHREAD_PROCESS_PRIVATE, max);

pour l'instant j'ai définit la macro comme ça, je vais voir smile

(la version pour windows de la macro n'utilise pas le name, donc j'en déduis que c'est pas important?)

Dernière modification par tshirtman (Le 01/11/2012, à 18:59)

Hors ligne

#2389 Le 01/11/2012, à 19:08

grim7reaper

Re : /* Topic des codeurs [7] */

Non, name c’est pour le nom du fichier (mais là du coup on fait un sémaphore anonyme).
Sinon, c’est plutôt val que max qu’il faut passer en 3e paramètre de sem_init.

Par contre, c’est pas si simple de modifier le code.
Là, le test d’échec est dans les choux (il va toujours renvoyer vrai), la fermeture du sémaphore va échouer (dans le meilleur des cas, car sem_close c’est pour un sémaphore nommé : on passe par sem_destroy pour un sémaphore anonyme), et peut-être d’autres trucs que j’ai pas encore regardé.
C’est pas insurmontable, mais on ne peux pas se contenter de juste substituer la macro wink

Dernière modification par grim7reaper (Le 01/11/2012, à 19:15)

Hors ligne

#2391 Le 01/11/2012, à 19:33

Steap

Re : /* Topic des codeurs [7] */

Ca vaudrait pas le coup de rapporter le bug ? tongue


GNU Guix, un gestionnaire de paquets fonctionnel.

Hors ligne

#2392 Le 01/11/2012, à 19:38

grim7reaper

Re : /* Topic des codeurs [7] */

tshirtman a écrit :

arf tongue je peut remplacer la macro SEM_CLOSE aussi alors? tongue

Du coup faudrait ouais ^^
Et SEM_HANDLE.
Après, faut voir ce qu’on peut faire pour la condition.
Y’a pas une suite de test pour vérifier qu’on pète rien ?

Parce si on fait un truc qui tiens la route, ça pourrais valoir le coup de proposer les patch comme je l’avais évoqué plus tôt (et comme Steap viens de le suggérer aussi).

Dernière modification par grim7reaper (Le 01/11/2012, à 19:38)

Hors ligne

#2393 Le 01/11/2012, à 19:52

tshirtman

Hors ligne

#2394 Le 01/11/2012, à 20:05

tshirtman

Re : /* Topic des codeurs [7] */

changer la macro SEM_CLOSE
#define SEM_CLOSE(sem) sem_destroy(sem)

je pense que c'est bon, mais SEM_HANDLE, je vois moins…

Hors ligne

#2395 Le 01/11/2012, à 20:19

grim7reaper

Re : /* Topic des codeurs [7] */

Je vais essayer de te faire un patch dans la soirée, a priori ça devrait pas me prendre longtemps.
Je fais ça dès que j’ai un moment.

Hors ligne

#2396 Le 01/11/2012, à 20:30

tshirtman

Re : /* Topic des codeurs [7] */

smile merci, par ce que là j'ai du rater un truc ^^

/home/gabriel/python-for-android/build/python/Python-2.7.2/Modules/_multiprocessing/semaphore.c: In function 'semlock_new':
/home/gabriel/python-for-android/build/python/Python-2.7.2/Modules/_multiprocessing/semaphore.c:439: error: 'PTHREAD_PROCESS_PRIVATE' undeclared (first use in this function)
/home/gabriel/python-for-android/build/python/Python-2.7.2/Modules/_multiprocessing/semaphore.c:439: error: (Each undeclared identifier is reported only once
/home/gabriel/python-for-android/build/python/Python-2.7.2/Modules/_multiprocessing/semaphore.c:439: error: for each function it appears in.)
/home/gabriel/python-for-android/build/python/Python-2.7.2/Modules/_multiprocessing/semaphore.c:439: warning: passing argument 1 of 'sem_init' makes pointer from integer without a cast
/home/gabriel/android-ndk-r7/platforms/android-14/arch-arm/usr/include/semaphore.h:46: note: expected 'struct sem_t *' but argument is of type 'int'

la première c'est surement un include qui manque, mais l'autre ça doit être ce dont tu parlais smile

Dernière modification par tshirtman (Le 01/11/2012, à 20:31)

Hors ligne

#2397 Le 01/11/2012, à 22:22

grim7reaper

Re : /* Topic des codeurs [7] */

Bon, en fait modifier SEM_HANDLE c’était pas le bon plan (ça demandait de modifier beaucoup de code, donc c’est moche).
Du coup, j’ai plutôt refait SEM_CREATE et SEM_CLOSE (mais elles deviennent des petites fonctions pour le coup).
J’en ai profité pour virer SEM_UNLINK qui devenait inutile du coup.
Voilà le patch fix-semaphore.patch

--- Python-2.7.2/Modules/_multiprocessing/semaphore.c.orig      2012-11-01 21:52:08.729279756 +0100
+++ Python-2.7.2/Modules/_multiprocessing/semaphore.c   2012-11-01 22:09:20.037257214 +0100
@@ -35,7 +35,6 @@
 #define SEM_CREATE(name, val, max) CreateSemaphore(NULL, val, max, NULL)
 #define SEM_CLOSE(sem) (CloseHandle(sem) ? 0 : -1)
 #define SEM_GETVALUE(sem, pval) _GetSemaphoreValue(sem, pval)
-#define SEM_UNLINK(name) 0
 
 static int
 _GetSemaphoreValue(HANDLE handle, long *value)
@@ -192,14 +191,32 @@
 
 #define SEM_CLEAR_ERROR()
 #define SEM_GET_LAST_ERROR() 0
-#define SEM_CREATE(name, val, max) sem_open(name, O_CREAT | O_EXCL, 0600, val)
-#define SEM_CLOSE(sem) sem_close(sem)
 #define SEM_GETVALUE(sem, pval) sem_getvalue(sem, pval)
-#define SEM_UNLINK(name) sem_unlink(name)
 
-#ifndef HAVE_SEM_UNLINK
-#  define sem_unlink(name) 0
-#endif
+static sem_t*
+SEM_CREATE(name, val, max)
+{
+    sem_t *sem = malloc(sizeof *sem);
+
+    if (sem == NULL)
+        goto failure;
+
+    if (sem_init(sem, 0, val) == -1)
+        goto failure;
+
+    return sem;
+
+failure:
+    return SEM_FAILED;
+}
+
+static int
+SEM_CLOSE(sem_t *sem)
+{
+    int status = sem_destroy(sem);
+    free(sem);
+    return status;
+}
 
 #ifndef HAVE_SEM_TIMEDWAIT
 #  define sem_timedwait(sem,deadline) sem_timedwait_save(sem,deadline,_save)
@@ -441,9 +458,6 @@
     if (handle == SEM_FAILED || SEM_GET_LAST_ERROR() != 0)
         goto failure;
 
-    if (SEM_UNLINK(buffer) < 0)
-        goto failure;
-
     result = newsemlockobject(type, handle, kind, maxvalue);
     if (!result)
         goto failure;

Ça compile bien.

Au passage, dans l’idéal il faudrait (dans multiprocessing.h) remplacer :

#  if defined(HAVE_SEM_OPEN) && !defined(POSIX_SEMAPHORES_NOT_ENABLED)
#    include <semaphore.h>
     typedef sem_t *SEM_HANDLE;
#  endif

par

#  if !defined(POSIX_SEMAPHORES_NOT_ENABLED)
#    include <semaphore.h>
     typedef sem_t *SEM_HANDLE;
#  endif

étant donné que sem_open n’est plus nécessaire…
Voire faire sauter le check de sem_open lors du configure, à voir.

Hors ligne

#2398 Le 01/11/2012, à 22:54

tshirtman

Re : /* Topic des codeurs [7] */

OMG un goto!


(oui je sors ^^)

Dernière modification par tshirtman (Le 01/11/2012, à 22:54)

Hors ligne

#2399 Le 01/11/2012, à 23:11

grim7reaper

Re : /* Topic des codeurs [7] */

Bha j’essaye de respecter la guideline du code Python. Et dans le code, il y en a (7 dans rien que dans connection.h du module multiprocessing), donc j’en déduit que c’est pas trop mal vu :]

grim7reaper@morning Python-2.7.2]$grep -r goto * | wc -l
4082

Au passage, j’en ajoute deux mais j’en retire un donc c’est ça va hein tongue

Dernière modification par grim7reaper (Le 01/11/2012, à 23:12)

Hors ligne

#2400 Le 01/11/2012, à 23:16

Pylades

Re : /* Topic des codeurs [7] */

(N’empêche que mettre directement un return économiserait deux lignes et me paraît plus clair. tongue)


“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Hors ligne