/* Topic des codeurs [7] */

tshirtman · Le 01/11/2012, à 16:07

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.

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 .

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

Steap · Le 01/11/2012, à 16:10

@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.

grim7reaper · Le 01/11/2012, à 16:26

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)

Steap · Le 01/11/2012, à 16:28

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

grim7reaper · Le 01/11/2012, à 16:30

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)

grim7reaper · Le 01/11/2012, à 17:02

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)

tshirtman · Le 01/11/2012, à 17:11

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?

grim7reaper · Le 01/11/2012, à 17:12

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).

tshirtman · Le 01/11/2012, à 17:19

Ah oui j'avais pas vu l'edit… je teste ça.

Steap · Le 01/11/2012, à 17:21

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

tshirtman · Le 01/11/2012, à 17:26

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

edit: j'avais pris la mauvaise macro

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

grim7reaper · Le 01/11/2012, à 18:27

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)

tshirtman · Le 01/11/2012, à 18:58

#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

(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)

grim7reaper · Le 01/11/2012, à 19:08

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

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

tshirtman · Le 01/11/2012, à 19:29

arf je peut remplacer la macro SEM_CLOSE aussi alors?

Steap · Le 01/11/2012, à 19:33

Ca vaudrait pas le coup de rapporter le bug ?

grim7reaper · Le 01/11/2012, à 19:38

tshirtman a écrit :

arf je peut remplacer la macro SEM_CLOSE aussi alors?

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)

tshirtman · Le 01/11/2012, à 19:52

Oui, si on fait un truc qui marche, ça vaudrait sans doute le coup.

tshirtman · Le 01/11/2012, à 20:05

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

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

grim7reaper · Le 01/11/2012, à 20:19

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.

tshirtman · Le 01/11/2012, à 20:30

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

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

grim7reaper · Le 01/11/2012, à 22:22

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.

tshirtman · Le 01/11/2012, à 22:54

OMG un goto!

(oui je sors ^^)

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

grim7reaper · Le 01/11/2012, à 23:11

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

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

Pylades · Le 01/11/2012, à 23:16

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

Ubuntu-fr

Navigation

Liens de recherche

Annonce

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#2384 Le 01/11/2012, à 17:19

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

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

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

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

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

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

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

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

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

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

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

#2390 Le 01/11/2012, à 19:29

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pied de page des forums