Yop,

Grosse mise à jour ce matin avec pas mal de nouveautés, il y a plus qu'à croiser les doigts que tout se passe sans trop de 500

-Amélioration de perf sur les modules d'output html, gain notable de 20% sur certaines pages, le CPU me remercie d'avance
-Amélioration très notable sur des pages backend qui pouvaient parfois bouffer tout le CPU pendant plusieurs minutes, là ça devrait plus jamais faire chier
-Correction (en principe je croise les doigts à fond pour celle ci) d'un bug historique qui empêchait la mise en // des requêtes, la aussi, en principe, on devrait voir le bénéfice de cela en période de forte charge

Avec ça, il y a une nouvelle fritoure en test qui va débarquer, je dois modifier encore quelques pages et ce sera online d'ici tout à l'heure.

Suite au prochain numéro

Ah, bon, 10min et la première 500, mince
Bon y a peut être encore du tuning à faire pour la mise en //, mais je suis confiant ce coup ci

Les threads c'est le mal...

phil> Aha, je m'attendais un peu à ta réaction, j'y ai pas mal réfléchi, mais tout l'écosystème dans lequel je travaille est fortement multi threadé, pour en profiter il faut faire pareil

De plus, comment sans multi thread tu utilises au mieux un quad core si tu n'as sur le principe que 2 processus gourmands qui fonctionnent? 2 * 1 thread ça suffira pas

Multiprocess, avec message passing si nécessaire
De toutes façons, même en multithread, si tu as beaucoup de sections critiques, tes multicores te sont de peu d'utilité.

Mais je comprends bien ton problème, c'est difficile d'intégrer les deux, car tu ne peux pas profiter des avantages du single thread tant que tu as encore de morceaux multithread...

Je ne pourrai jamais en profiter, vu que j'utilise intensivement des trucs comme... MySQL

Je n'aime pas trop le principe du multiprocess dans mon cas, car le process de base consomme beaucoup de mémoire et si je dois avoir admettons 20 clients en //, tu admets que de base cela consomme 50MB pour diverses options, cela fait 1GB dans la gueule sans rien faire. Et on ne compte encore que 20 en //... 20 en // sur la même version multi thread, je n'aurai pas cette montée en consommation

Le même process lancé plusieurs fois ne consomme qu'une fois la mémoire du code et des RODATA. Seules les variables modifiées après le fork provoquent une duplication (copy on write). Et je ne pense pas que tu aies 50 MB de contexte par session.
De plus la gestion de sessions parallèles se fait facilement dans le même process unithread, donc tu dois juste lancer autant de process que tu as de cores pour profiter de tes quad core.

Pour MySQL, je ne vois pas en quoi il te handicape, c'est déjà un process séparé avec lequel on communique par messages, il faut juste utiliser un API asynchrone plutôt que l'API de la lib mysql.

Mais de façon générale, il est vrai que pour utiliser de façon asynchrone une librairie synchrone, on peut (doit) se permettre de lancer un thread pour exécuter la requête et renvoyer le résultat par un message vers la boucle principale. Ou de trouver/réécrire un API asynchrone de remplacement. Exemple typique: l'API POSIX de résolution DNS (gethostbyname/getaddrinfo) est synchrone. Ares, et adns sont des équivalents asynchrones indispensables seulement si on veut éviter les threads à tout prix.

Mais je ne te demande nullement de réécrire ton appli en asynchrone, donc pas besoin de chercher des arguments techniques pour ne pas le faire (car je continuerai à les démonter ).

L'asynchrone est bien trop méconnu, je continue ma propagande, mais je peux te dire qu'au boulot, tous les développeurs qui ont eu le déclic ne jurent plus que par ça.

Benh détrompe toi, j'ai énormément de données en mémoire par utilisateur, pour des caches, pour des infos de session, et pas juste 100k comme tu pourrais croire

Puis il y a énormément (mais alors énormément) de tables en mémoire comme pour n'en citer qu'une, les utilisateurs (ou la shoutbox, ou ...), et passer tout ça en mémoire partagée il n'en est absolument pas question

Mais si on enlève ces arguments, le principe de mon appli reste fort linéaire, exécution successive de milliers de procédures qui ne peuvent que rarement fonctionner sans attendre le résultat du module précédent

(Et t'as raison, de toute façon je changerai probablement jamais de principe sur ce projet )

Multi-process ou multi-thread, pour moi c'est le même combat.

Ce qu'on peut faire avec un process, il y a moyen de le faire encore plus facilement avec un thread. Le tout étant de ce mettre d'accord sur un principe de fonctionnement.

Ce que je retiens surtout du multi-process, c'est que c'est un mode que les gens adorent parce qu'on peut coder comme des porcs. Des variables globales à n'en plus finir, des systèmes de monitoring qui relance les process qui se cassent la figure parce que "core dump", ...

En multi-thread, ce ne sont pas des options valables! Et va porter sous windows une application multi-process .... hum ...

Evidement en multi-thread il y a moyen de faire le cochon, mais ça, il y a toujours moyen de pervertir une technologie.

Quant aux scheduling, que ton process attende sur un IO ou un semaphore, c'est exactement la même chose qu'un thread qui attend sur un pthread_lock ...

Avec evidement l'avantage d'arrêter de jouer avec des copy-on-write etc ...

Autant je partage l'interêt de la programmation "par message", autant je ne comprend pas cet acharnement au multi-process ...

rfr dans mes bras!
décidément...

J'adore la programmation par message, mais elle ne s'applique pas à tous les cas

Si vous acceptez le message passing, vous n'avez plus aucune bonne raison de vouloir absolument des threads avec des variables partagées et du locking. Si tu fais du strict message passing, tu peux le faire avec des threads comme avec des process puisque tu n'as plus besoin d'aucune autre primitive de synchronisation (autre que le message)

Quand je parle de multiprocess, je ne parle pas non plus du système de pre forking d'apache. Je parle juste d'une solution à la question de zion pour utiliser ses multicores. Moi j'ai en général assez avec un seul process Les autres cores peuvent aussi servir à faire tourner mySQL, les I/O et la crypto.

rfr> Ce que je hais particulièrement dans la programmation multithread, c'est que les gens programment comme des porcs avec des variables globales et des mutex ou des sémaphores pour tenter de les protéger... Tout ça parce qu'ils n'arrivent pas à penser en termes autres que séquentiel qu'ils ont appris avec le BASIC... Et que quand ça plante, c'est une condition de course que rien ne te permet de reproduire, ni le debugger, ni les traces (qui changent le timing).

Combien de prétendus professionels de l'informatique savent ce qu'est une continuation ou un CallCC ?

Quid quand t'arrives à des processeur 64 cores comme certains? T'en fais quoi de tes 60 autres cores?

Comment pourrait-on lancer un contest pour mettre fin à cette guerre des architectures?

Ce que je me dis aussi, c'est que des tas de gens "qui savent ce qu'ils font" ont inventer quelque chose de merveilleux dans les OS qu'on appelle les "scheduler".

Un TSS, c'est une forme de call/cc

Les TSS servent autant au process switch qu'au thread switch
Le Call/CC, c'est toi qui l'appelle, le thread switch, c'est le scheduler qui le fait quand ça lui chante.

Le problème avec les threads c'est justement le scheduler et la préemption, indispensable pour tolérer du busy waiting dans les threads (et donc indispensable à ceux qui pollent une variable globale dans un while(true) pour communiquer entre deux threads). C'est elle qui multiplie exponentiellement le state implicite de ton programme, puisque le context switch peut se passer n'importe où dans chacun de tes threads, même en plein milieu d'un statement C.

Sans préemption, on ne parle pas de threads, mais de coroutines, et ce modèle là est totalement équivalent au modèle purement asynchrone single thread puisque les context switches sont clairement maîtrisés. Moi j'appelle ça l'asynchrone séquentiel, d'autres appellent ça les "inline callbacks".