[PHP 5.2] Passer une référence d'une archive zip à un script php via exec

[foxpowa]

Bonjour à tous,

je rencontre des difficultés dans un script php dans lequel j'utilise la libraire php multi process.
La libraire ne pose pas de problème en soi. J'aimerai simplement passer un zip handle (Classe ZIPARCHIVE) aux scripts fils afin qu'ils y copient des fichiers.

Les portions de code :
script père :

Code :

1
2
3
4
5
6
7
8
9
 
...
$processes[] = array('path'=>'/path/to/seq_dispatch_para.php','variables'=>array('fichier' => $fichier, 'fichier_root' => $fichier_root, 'plate_name' => $plate_name, 'zip_handle' => &$zip));
...
$mp = new multi_process();
$mp->createChildren($processes);
$mp->checkStatus();
$mp->cleanup();
...

script fils :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
...
$mp = new childProcess($argv);
$var = $mp->getVariables();
...
$zip = $var['zip_handle'];
if($zip->addEmptyDir('TEST'))
{
      ...;
}
....

Il faut savoir que les variable passées du père au fils sont stocké dans une db mysql de "cache" et encodées via base64().

Avez vous des idées pour que mes scripts fils puissent tous accéder au même zip handle ?
Merci

[Benjamin Delespierre]

Il faut savoir que les variable passées du père au fils sont stocké dans une db mysql de "cache" et encodées via base64().

Aïe. Je vois pas l'intérêt de faire des pseudo forks (surtout à coups d'exec comme c'est le cas dans ta lib) sans pouvoir utiliser un espace commun pour les données et vu que les requêtes SQL sont les opérations les plus coûteuses (traditionnellement) d'un script utiliser la DB comme espace global relève selon moi du bidouillage... J'aurais plutôt vu Redis ou MemCached pour faire ça.

Bref, tu ne peux pas passer un handle de type Ressource car ils ne sont pas sérializable (regarde la doc de PHP pour plus de détails). En fait, les variables qui transitent entre les scripts par $_SESSION par exemple sont toujours encodées et décodées sous forme de chaine de caractères, or une ressource ne peut pas subir un tel traitement. Ce qu'il faut donc que tu fasses pour palier à ça serait de créer une structure de données (un tableau ou un objet pourraient faire l'affaire) et que cette structure permette de "recréer" le handle dans l'état ou il était dans le script parent.
Regarde du coté de __sleep et __wakeup ça te donnera des idées.

[foxpowa]

Merci pour ta réponse.
J'avoue qu'utiliser une DB comme espace global est limitant en terme de vitesse, mais c'était la seule chose que j'appréhendais correctement. A ce sujet, je vais aller me renseigner sur Redis et memcached.

Ce qu'il faut donc que tu fasses pour palier à ça serait de créer une structure de données (un tableau ou un objet pourraient faire l'affaire) et que cette structure permette de "recréer" le handle dans l'état

Le problème avec ZipArchive c'est qu'on ne peut pas ouvrir plus d'une fois la même archive. Au départ je procédais comme tu le dis, à savoir de filer les infos pour ouvrir l'archive dans le fils, mais les scripts fils, tournant en parallèle, me renvoyaient une erreur...

EDIT : Redis ne gère au final que des variables de types string int array ... mais pas de handle de fichier, non ?

It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.

[Benjamin Delespierre]

Le problème avec ZipArchive c'est qu'on ne peut pas ouvrir plus d'une fois la même archive

Alors il faut que lors de l'accès à la ressource les différents process impliqués lockent le fichier et détruisent le lock (et ferment la ressource) quand ils ont fini, ce qui annule totalement l'avantage d'utiliser le pseudo parallélisme. Tu peux locker un fichier avec flock.

-- Edit

Je pense que ce que tu cherches à faire peut être rattaché au design pattern Chain of responsibilities, tu devrais y jeter un oeil.

[foxpowa]

Ouai effectivement ça annule l'utilité du pseudo parallélisme.
Du coup c'est pas terrible, puisque mon but premier c'est d'aller plus vite qu'avec la 1 ère version du script.

Avec memcached ce bout de code me permettrait il de stocker et récupérer un handle ?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
//Dans le père
$m = new Memcached();
$m->addServer('localhost', 11211);
$m->set('foo', $handle);
...
//j'envoie l'objet sérialisé
...
 
//que je récupère
//dans le fils
$m = new Memcached();
$m->addServer('localhost', 11211);
$m->get('foo');

EDIT : Ce que je cherche à faire c'est ouvrir une archive zip dans un script père, filer le handle aux x scripts fils lancés à partir du père. Insérer des fichiers dans cette archive après traitement sur les dits fichiers, rangés dans répertoires bien précis.
Le père attends que tous les fils aient finis et balance le zip en dl via un header('location : blabla.zip')

[Benjamin Delespierre]

Avec memcached ce bout de code me permettrait il de stocker et récupérer un handle ?

Non plus, c'est toujours pareil, si tu sors de PHP, il faut sérialiser et là PAN.

La solution pour toi est de n'avoir qu'un seul script à lancer en "arrière plan" du script parent.

[foxpowa]

OK.
Le problème c'est que j'ai pensé à cette pseudo parallélisation car le script initial tournait avec un foreach, dans le style :

Code :

1
2
3
4
5
6
 
foreach($array as $file)
{
     //fait 2,3 trucs
     // $zip->addFile($source_file,$destination_file);
}

Ca met un temps conséquent pour plus de 200 fichiers à traiter (logique vu les traitements), mais le plus problématique c'est que l'archive finale n'est souvent pas complète ou invalide.
D'où mon idée de pseudo paralléliser ce foreach.

Je suppose que ça doit être pareil en Perl au niveau du passage d'handle d'un script à un script fils ... ?

[Benjamin Delespierre]

Je suppose que ça doit être pareil en Perl au niveau du passage d'handle d'un script à un script fils ... ?

Je sais pas... Je pense que tu as besoin de repenser ta solution.

[foxpowa]

J'ai repris le script de mon prédécesseur et je suis ouvert à toute proposition.
J'ai même tenter de créer l'arborescence et les fichiers directement sur le serveur, dans un répertoire temporaire via les scripts fils.
Et de d'archiver le tout dans le script père ...
C'est pas terrible ... Les lenteurs sont toujours là....
Mais je pense creuser dans cette voie en essayant d'aller plus loin.

Merci pour vos conseils!