@rthur merci pour les info

Le multithreading en web moi j'y crois pas des masses, il faut avoir besoin de faire deux choses distinctes à un même moment, et on parle de millisecondes et typiquement de jouer avec un système de données externe (sgbd, filesystem, daemon quelconque), c'est un besoin très "petit" pour les tâches du dev web, en revanche pour du client lourd ou du système oui évidemment le multithreading prend tout son sens.

cela dépend du contexte. Pour les applications classique grand publique effectivement besoin très rare sachant que la plus part du temps on se démerde avec une iframe coté client pour gérer des choses "en même temps". Sachant que le coté multithread est simulé par le serveur web (qui l'est lui pour le coup).

Par contre pour de l'application "professionnelle" c'est possible. on peu imaginer, par exemple, l'utilisation d'un gros traitement coté serveur (plusieurs minutes / heures) et de vouloir et de rendre la main pour que l'application fasse ce qu'elle veux derrière (et pourquoi du pooling ajax ou push websocket pour connaitre l'état du traitement). Cela se fait simplement en exécutant un nouveau thread

Alors oui c'est des cas particulier mais des fois c'est bien pratique (la en php faut exécuter un script dans la nature et essayer par un biais quelconque d'avoir le résultat. c'est pas super simple



@+

Merci Moogli, ta réponse m'éclaire un peu sur l'utilité du multi-threading. Je n'y comprenais rien, mais ça commence à m'intéresser.
J'ai, effectivement, eu besoin d'iframe pour contourner certains défis de mises à jours de sections de page.
Je m'y pencherai.

Dans un cadre classique sur une page web le multithreading ne sert à rien pour un client seul et doit franchement être évité. Par contre en ligne de commande ça peut avoir son utilité, dans la gestion d'une Queue par exemple afin de paralléliser des taches pour accélérer le traitement. C'est ce que fait l'implémentation PHP de Resque par exemple (un gestionnaire de queue / worker codé par Github), il lance des fork afin d'isoler la tâche en cours (ce qui évite les fuites de mémoire) et de traiter plus vite la Queue.

Bonjour,

Il est bon de rappeler également que PHP7 change la façon dont les sessions sont désérialisées ce qui peut nécessiter une mise à jour du code entre PHP5.6 et PHP7 sans rétrocomptabilité. Sinon PHP7 est vraiment mieux.
Il faut noter aussi pour le moment que le driver PDO pour SQL Server n'est toujours pas disponible pour PHP7. J'ai vu qu'un driver ODBC était sorti mais il n'est malheureusement pas compatible avec SQL Server 2016 car il utilise la version 11 d'odbc et SQL Server 16 tourne avec la nouvelle version 13. Sachez toutefois que la version 11 fonctionne pour SQL Server 2016, mais cela vous obligera a désactiver SQL Agent, la version 11 et 13 ne pouvant cohéxister sur la même machine.

++

Les drivers sont maintenant disponibles ici https://www.microsoft.com/en-us/downloa ... x?id=20098