OVH Cloud OVH Cloud

thread-safe and co

5 réponses
Avatar
stef
Salut à tous,

Je suis en train de faire un extension sous PHP5 qui sera donc charge en
module persistant sous Apache... ok

Dans cette extension je dois créer un "pool" de variables (qui en fait est
une liste de chaine)
J'ai toutes une batterie de fonctions pour gerer en C cette liste de chaine
(ajout suppression modif)
J'ai donc besoin de faire ca de facon multi-thread

J'ai vu que l'API ZNED proposait du thread-safe mais ca n'a l'air de ne
marche que sur des variables.
Moi j'ai plutot besoin d'un truc style mutex avec l'idée sous-jacentes

PHP_TEST_FUNCTION(.....)
{
....
mutex_lock;
variables tableau globales => ajout/modification/d'element
mutex_unlock;
}

On peut faire ca avec des fonctions du TSRM (g pas vi granc hose dans la doc
PHP)
ou dois-je passer directement avec la lib pthread ?

Interessant non ?

Merci d'avance


a++

5 réponses

Avatar
loufoque
stef a dit le 29/04/2005 à 19:17:

On peut faire ca avec des fonctions du TSRM (g pas vi granc hose dans la doc
PHP) [...] ?


Apparemment.
Je t'avoue que je ne sais pas trop ce qu'il y a de disponible et je sais
pas où c'est documenté, mais tu peux voir des trucs intéressants dans
les entêtes de TSRM

TSRM_API MUTEX_T tsrm_mutex_alloc(void);
TSRM_API void tsrm_mutex_free(MUTEX_T mutexp);
TSRM_API int tsrm_mutex_lock(MUTEX_T mutexp);
TSRM_API int tsrm_mutex_unlock(MUTEX_T mutexp);

Sinon, à part ça, elle sert à quoi ton extension ?

Avatar
stef
Slt,

TSRM_API MUTEX_T tsrm_mutex_alloc(void);
TSRM_API void tsrm_mutex_free(MUTEX_T mutexp);
TSRM_API int tsrm_mutex_lock(MUTEX_T mutexp);
TSRM_API int tsrm_mutex_unlock(MUTEX_T mutexp);


Ouais g remarqué les trsm_mutex(...) merci c cool.


Sinon, à part ça, elle sert à quoi ton extension ?


L'extension est pour mon boulot, un accés à des routines "homemade"



Globalement, je trouve que créer des extensions avec PHP n'est pas une
affaire "simple"
Non pas parce que c'est compliqué, mais parce que c'est le foutoir.

Quelques remarques en passant :

- Je me trompe où PHP n'a pas l'air a l'aise avec le multi-thread ?
En tout cas ca se ressent dans les extensions (voir certains modules dans
/ext)

- L'API ZEND me semble assez obscure (mais je pense que cela vient de la doc
qui est carrément... nulle - désolé)

- Les sources des modules (/ext) souffrent d'un manque d'homogénéïté
flagrant
Pas ou peux de commentaires (ok c pas censé être un tutoriel, mais bon.),
certains modules utilisent
des méthodes différentes pour arriver au même résultat.


- Et surtout LE reproche : la documentation - en général - est franchement
très (très) pauvre.
Mis à part quelques trucs sur google, keud !
En plus ce sont toujours les mêmes types d'articles style
"zend_printf("Hello world")" et ca ne va pas plus loin !!!


Quand on voit la dose de doc. sur Java et son JNI...

Tiens je crois que je vais jeter un oeil sur les servlets (un tank, mais au
moins c clair !)
Ca m'emm*** car je trouve PHP sympa.

Merci à tous
a++

Avatar
John GALLET
Bonjour,

Je suis en train de faire un extension sous PHP5 qui sera donc charge en
module persistant sous Apache... ok
Jusqu'ici tout va bien. La vraie question c'est de savoir si tu veux

utiliser apache 2, ce qui a mon sens n'a aucun intérêt, ou rester en
module sous apache 1.3.x

Dans cette extension je dois créer un "pool" de variables (qui en fait est
une liste de chaine)
Dans Zend , ce sont des "ressources".


J'ai toutes une batterie de fonctions pour gerer en C cette liste de chaine
(ajout suppression modif)
J'ai donc besoin de faire ca de facon multi-thread
Pas nécessairement, non.


J'ai vu que l'API ZNED proposait du thread-safe mais ca n'a l'air de ne
marche que sur des variables.
Certes pas, comment voudrais tu que php fonctionne avec apache 2 si

c'était le cas ?

Interessant non ?
Bof. Tout le code source de php, toutes les extensions, est disponible. Tu

en prends une qui est réputée être thread-safe sous apache 2, donc a
priori : n'importe laquelle, et tu regardes comment c'est fait. Ca a même
un nom, ça s'appelle du hacking, au vrai sens du terme.

Perso je ferai ça avec une ressource. L'initialisation de la ressource
elle même a lieu lors du chargement du module, donc pas thread safety à
gérer, et ensuite, je ne vois pas comment les api d'ajout dans une
ressources ne seraient pas thread-safe.

Enfinen tous cas, moi je m'emmerderais pas avec des threads, ça sert
clairement à rien à part à se torturer l'esprit quand on a du multi-fork.

a++;
JG

Avatar
John GALLET
Globalement, je trouve que créer des extensions avec PHP n'est pas une
affaire "simple"
Ce qui m'a pris le plus de temps, c'est de corriger les conneries dans la

doc à propos des .m4... (d'ailleurs le commentaire que j'ai fait à ce
propos est toujours dans les user comments du chapitre 47 de la doc)

Non pas parce que c'est compliqué, mais parce que c'est le foutoir.
Parlons en.


Quelques remarques en passant :
- Je me trompe où PHP n'a pas l'air a l'aise avec le multi-thread ?
En tout cas ca se ressent dans les extensions (voir certains modules dans
/ext)
A mon sens, Zend est thread safe, mais n'oublions pas que ça ne sert

absolument à RIEN de l'être en multi-fork comme l'est apache.

- L'API ZEND me semble assez obscure (mais je pense que cela vient de la doc
qui est carrément... nulle - désolé)
Par rapport, puisque tu en parles, à celle de JNI, elle est géniale.


- Les sources des modules (/ext) souffrent d'un manque d'homogénéïté
flagrant
Normal, ce sont des gens qui ne se connaissent pas qui les ont écrites.


Pas ou peux de commentaires (ok c pas censé être un tutoriel, mais bon.),
certains modules utilisent
des méthodes différentes pour arriver au même résultat.
Ah ? Parce que tu connais UNE SEULE méthode pour arriver à la même chose

en développement toi ?

- Et surtout LE reproche : la documentation - en général - est franchement
très (très) pauvre.
Qu'est-ce qui te manque dans le manuel ?


Mis à part quelques trucs sur google, keud !
Et ça c'est quoi ?

http://fr2.php.net/manual/en/zend.php

En plus ce sont toujours les mêmes types d'articles style
"zend_printf("Hello world")" et ca ne va pas plus loin !!!
Ca te suffit pas, avec tout le code de php à dispo ??


Quand on voit la dose de doc. sur Java et son JNI...
Parlons en, oui. Une belle merde. Quand je pense que tu es obligé de

caster les int en (jint) quand tu appelles un constructeur java depuis JNI
sinon ça core, c'est écrit où ça dans leur putain de doc que les même les
int ils les ont pourris ces cons ??

Il m'a fallu 3 semaines de boulot pour intégrer une api complète en
extension Zend. Il m'a fallu 2 mois pour l'intégrer, ensuite, en JNI. En
JNI justement non seulement tu as encore moins de doc mais en plus tu ne
trouveras pas un seul exemple complet de module qui tourne vraiment en
production.

Tiens je crois que je vais jeter un oeil sur les servlets (un tank, mais au
moins c clair !)
Ca va pas t'aider à intégrer du C ou du C++, sauf à passer par un wrapper

JNI.

a+;
JG

Avatar
stef
Slt,
Une fois de plus on tombe sur de l'extreme, dommage :(

"John GALLET" wrote in message
news:
Globalement, je trouve que créer des extensions avec PHP n'est pas une
affaire "simple"
Ce qui m'a pris le plus de temps, c'est de corriger les conneries dans la

doc à propos des .m4... (d'ailleurs le commentaire que j'ai fait à ce
propos est toujours dans les user comments du chapitre 47 de la doc)


super, et si tu en profitais aussi pour refaire toute la doc de Zend que
cela soit au moins utile à quelqu'un

Non pas parce que c'est compliqué, mais parce que c'est le foutoir.
Parlons en.


Quelques remarques en passant :
- Je me trompe où PHP n'a pas l'air a l'aise avec le multi-thread ?
En tout cas ca se ressent dans les extensions (voir certains modules
dans


/ext)
A mon sens, Zend est thread safe, mais n'oublions pas que ça ne sert

absolument à RIEN de l'être en multi-fork comme l'est apache.


Sauf si tu es sous Win32, tu sais le truc qui digere assez mal le fork


- L'API ZEND me semble assez obscure (mais je pense que cela vient de la
doc


qui est carrément... nulle - désolé)
Par rapport, puisque tu en parles, à celle de JNI, elle est géniale.



Ouais ok je vois...

- Les sources des modules (/ext) souffrent d'un manque d'homogénéïté
flagrant
Normal, ce sont des gens qui ne se connaissent pas qui les ont écrites.



En gros t'es en train de dire que les mecs qui ecrivent les extensions n'y
comprennent rien !


Pas ou peux de commentaires (ok c pas censé être un tutoriel, mais
bon.),


certains modules utilisent
des méthodes différentes pour arriver au même résultat.
Ah ? Parce que tu connais UNE SEULE méthode pour arriver à la même chose

en développement toi ?


C'est peut-etre la le probleme !!!


- Et surtout LE reproche : la documentation - en général - est
franchement


très (très) pauvre.
Qu'est-ce qui te manque dans le manuel ?


Mis à part quelques trucs sur google, keud !
Et ça c'est quoi ?

http://fr2.php.net/manual/en/zend.php


1 lien, ouaaah c'est trop.... arrete,
(en plus il n'apporte rien de plus au niveau des extensions, juste le
minimum encore une fois )


En plus ce sont toujours les mêmes types d'articles style
"zend_printf("Hello world")" et ca ne va pas plus loin !!!
Ca te suffit pas, avec tout le code de php à dispo ??



Bi non gros malin, justement...

Quand on voit la dose de doc. sur Java et son JNI...
Parlons en, oui. Une belle merde. Quand je pense que tu es obligé de

caster les int en (jint) quand tu appelles un constructeur java depuis JNI
sinon ça core, c'est écrit où ça dans leur putain de doc que les même les
int ils les ont pourris ces cons ??


Si la seule difficulté des extensions PHP était le cast, ca ne me
derangerait pas :)



Il m'a fallu 3 semaines de boulot pour intégrer une api complète en
extension Zend. Il m'a fallu 2 mois pour l'intégrer, ensuite, en JNI. En
JNI justement non seulement tu as encore moins de doc mais en plus tu ne
trouveras pas un seul exemple complet de module qui tourne vraiment en
production.


Tu dois etre special, car JNI meme s'il est lourd est plus clair (et il y a
de la doc désolé)




Tiens je crois que je vais jeter un oeil sur les servlets (un tank, mais
au


moins c clair !)
Ca va pas t'aider à intégrer du C ou du C++, sauf à passer par un wrapper

JNI.


C'est exactement ce que je veux faire, un wrapper.
T'as encore tout compris

pfff
Donc apres cette réponse hyper-constructive je comprends pourquoi c un peu
le boxon les extensions


goto Java

a++