C'est très drôle
Et très utile
Merci de tes conseils

Ecris donc un serveur TCP

Bon j'y une vague idée sur un problème avec un composant de Borland en serveur TCP vu qu'on dirait qu'il me tue mon process si il est en ThreadBlocking au moment ou il kille le thread...

J'ai plus le courage ce soir, la semaine prochaine je remplace ce serveur TCP par un autre

Farpaitement, mais je ne m'envoie aucun SIGSTOP, pourquoi il se bloque tout seul alors?

En version light (le moins de module), je ne me connecte à aucune DB et il me fait le même bordel

Il ne reste aucune autre connexion avec qui que ce soit

OK, mais les autres libs alors (Postgres, mysql, autre) ?
Un autre process auquel se connecte ton prog fastcgi ?

C'est pas un mode debug qui stoppe exprès après chaque requête ?

Si lighttpd est hors de cause, c'est donc ton programme

C'est con, c'est à priori le dernier "gros" problème pour une première alpha (alpha, j'ai pas dit avec tout qui marche ).

Suspense, ce sera pour quand ...

toi même, j'en ai ma claque des dépendances qui marchent plus et FASTCGI est pas non plus un truc hyper compliqué à réécrire... Puis surtout j'aurais pris aussi longtemps à utiliser une lib qu'à l'écrire vu qu'on sait rien utiliser en Pascal sans réécrire les headers



Un socket TCP, mais lighttpd est hors de cause

Mais est-ce qu'il peut recevoir un SIGSTOP par une erreur (exception, AV, etc, etc,) interne?

Parce que la je viens de dire à mon serveur Windows (absyss) d'aller se connecter à la version nunux (difficile pour la version Windows de lui envoyer un SIGSTOP ) et ce connard se fout quand même en "Stopped"

Sacrebleu, ce sera moins drôle à débugger que ce que je ne pensais

Que fait ton process à la fin de la requête ?
Le lien lighttpd-fastcgi est via un socket TCP ? Un socket Unix ? Un pipe ?
Si tu le fais via un socket TCP, tu peux mettre ethereal wireshark pour sniffer ce qui passe ?

Parce qu'il reçoit le signal SIGSTOP

Edith: ou le signal SIGTSTP, avec un CTRL-Z dans une console...