[KnuX]

Salut à tous,
Le sujet sans doute pas clair, mais je vais m'expliquer plus ici...

J'ai fait un client IRC en PHP. Ce client a certaines opérations à effectuer, notamment une requête vers une base de données créées avec SQLite (www.sqlite.org) et les drivers PDO+PDO_SQLITE disponibles sur www.php.net.

Comme le client se connecte à un serveur IRC, il doit répondre régulièrement à la requête "PING" envoyée par le serveur, par un "PONG". Souvent, le délai de réponse est de 3 minutes avant que le serveur considère la connection comme perdue.

Seulement voilà, il arrive que la requête puisse prendre plus de 3 minutes (pitié, ne pas décaler mon problème en rétorquant que la base n'est pas optimisée ou je ne sais quoi, ce n'est pas la clé du problème). Dans cette situation, le serveur coupe donc la connexion puisque la lecture/écriture sur la socket est "suspendue" le temps que PHP attende la réponse d'SQLite.

Je cherche donc à pouvoir dire à PHP d'aller exécuter la requête tout en le laissant continuer son travaille d'écoute et d'écriture sur la socket. En fait, j'imagine ça comme une fonction qui s'occuperait de la requête et qui en appellerait une autre une fois celle-ci terminée (ce qui est parfois appelé un "callback" donc).

Quelqu'un aurait-il une idée ? On m'a proposé d'utiliser le "fork", je ne m'y connais pas trop et je voudrais savoir s'il n'y a pas des solutions envisageables...

Merci d'avance

[fonji]

Si j'ai bien tout compris, tu cherches à faire de la programmation concurrente en php...
Ca m'étonnerai fortement que ce soit possible...

Désolé mais j'ai pas tant d'idée... L'ouverture temporaire d'une nouvelle fenêtre pour effectuer le pong ne répondrait pas au serveur car ça changerait le port du client et donc le serveur prendrait ceci comme venant d'ailleurs...

[KnuX]

Toujours pas trouvé non plus

[Rasqual]

Bonjour,
C'est une solution que je n'ai pas testé, donc je ne garantis pas son fonctionnement.
Quelqu'un a récemment commenté sur le manuel en ligne que register_shutdown_function() est la seule manière de faire de la programmation asynchrone (si on exclut PCNTL, qui est non portable, je suppose)
L'idée serait de lancer un autre processus en fond pour effectuer les opérations sur SQLite, en faisant attention à ne pas lancer de tâche concurrente sur la base.
Dès que son travail est terminé, le processus communique avec l'appelant, via une socket. Le gros du boulot ce serait de gérer les erreurs, ce qui risque d'être bordélique si on ne fait pas attention.

Si tu ne vises que *nix (ce qui serait dommage), tu peux essayer de forker, mais là je ne m'y connais pas trop non plus.

Voilà, j'espère que cela t'aidera un peu.

[Fred]

Ce genre d'exemple touche à la limite du php : il te faudrait 3 processus, l'un qui assure la liaison avec le serveur IRC, le second qui assure la liaison avec la base SQL et le dernier qui fasse l'interface avec l'utilisateur. Pour du temps réel, le PHP c'est quand même pas génial, mieux vaut sans doute tenter quelque chose en java ... tu as quelles contraintes pour ton projet ?

[KnuX]

Ce n'est pas un projet, et je n'ai pas de contraintes particulières.

Si je venais à devoir mettre en production cette application, ce serait sur une machine serveur qui ne dispose pas de la JVM

Mais bon, tant pis, pour l'instant je vais me contenter des performances d'sqlite3 qui sont nettement supérieures à celles de sqlite2, mon bot ne met même plus de 40 secondes pour chercher quelque chose

Si un jour je trouve une solution, je vous le dirais, merci pour l'aide

[fonji]

Sauf erreur pour un applet le serveur n'a pas besoin de jvm, mais le client oui...
Par contre, pour un servlet (donc du j2ee en gros), là c'est l'inverse... Je me trompe ?

[KnuX]

Ce n'est pas une applet

Ca se lance en ligne de commande et il n'y a pas d'interaction avec l'utilisateur (sauf avec d'autres clients IRC sur un salon )