mais je pense que un fcreate , un fopen ( read , write , read-write ) à condition que le mode w ne remette pas le size de la file à 0 associés à fseek ( avec les 3 possibilités ) et ftruncate auraient suffit
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP. Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne argumentation pour que ce soit accepté.
mais il semble que php se soit développé trop vite
Ça n'a rien à voir avec PHP. Comme je l'ai dit, c'est la faute à POSIX, et même UNIX (j'ai relu le manpage de la fonction open, et effectivement, c'est un comportement hérité d'UNIX). D'accord, ces flags ne sont pas très heureux, ils sont même trompeurs.
Quand à ton idée d'avoir plusieurs fonctions pour ouvrir un fichier, selon les fonctionnalités qu'on souhaite utiliser, ce n'ést pas forcément une bonne idée. En l'occurrence, à l'époque où la fonction a été conçue, il fallait respecter des contraintes importantes liées à la mémoire et à la puissance des processeurs. Une fonction unique était plus pertinente.
Mais c'est vrai que PHP pourrait fournir une interface plus simple-- Mais il en faudrait un réel usage, ce qui n'est pas le cas.
On 07/20/11 01:47, mb wrote:
mais je pense que
un fcreate , un fopen ( read , write , read-write )
à condition que le mode w ne remette pas le size de la file à 0
associés à fseek ( avec les 3 possibilités ) et ftruncate
auraient suffit
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP.
Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne
argumentation pour que ce soit accepté.
mais il semble que php se soit développé trop vite
Ça n'a rien à voir avec PHP. Comme je l'ai dit, c'est la faute à
POSIX, et même UNIX (j'ai relu le manpage de la fonction open, et
effectivement, c'est un comportement hérité d'UNIX). D'accord, ces flags
ne sont pas très heureux, ils sont même trompeurs.
Quand à ton idée d'avoir plusieurs fonctions pour ouvrir un fichier,
selon les fonctionnalités qu'on souhaite utiliser, ce n'ést pas
forcément une bonne idée. En l'occurrence, à l'époque où la fonction a
été conçue, il fallait respecter des contraintes importantes liées à la
mémoire et à la puissance des processeurs. Une fonction unique était
plus pertinente.
Mais c'est vrai que PHP pourrait fournir une interface plus simple--
Mais il en faudrait un réel usage, ce qui n'est pas le cas.
mais je pense que un fcreate , un fopen ( read , write , read-write ) à condition que le mode w ne remette pas le size de la file à 0 associés à fseek ( avec les 3 possibilités ) et ftruncate auraient suffit
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP. Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne argumentation pour que ce soit accepté.
mais il semble que php se soit développé trop vite
Ça n'a rien à voir avec PHP. Comme je l'ai dit, c'est la faute à POSIX, et même UNIX (j'ai relu le manpage de la fonction open, et effectivement, c'est un comportement hérité d'UNIX). D'accord, ces flags ne sont pas très heureux, ils sont même trompeurs.
Quand à ton idée d'avoir plusieurs fonctions pour ouvrir un fichier, selon les fonctionnalités qu'on souhaite utiliser, ce n'ést pas forcément une bonne idée. En l'occurrence, à l'époque où la fonction a été conçue, il fallait respecter des contraintes importantes liées à la mémoire et à la puissance des processeurs. Une fonction unique était plus pertinente.
Mais c'est vrai que PHP pourrait fournir une interface plus simple-- Mais il en faudrait un réel usage, ce qui n'est pas le cas.
mb
In article <4e2bb509$0$7293$, Mickael Wolff wrote:
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP. Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne argumentation pour que ce soit accepté.
le principe de l'inclusion d'un php par du C m'échappe totalement ceci dit je n'ai pas besoin d'une puissance extraordinaire ( juste amateur )
mais d'accord , je vais écrire des fct php "singeant" le comportement dont j'ai l'habitude
> mais il semble que php se soit développé trop vite
Ça n'a rien à voir avec PHP. Comme je l'ai dit, c'est la faute à POSIX, et même UNIX (j'ai relu le manpage de la fonction open, et effectivement, c'est un comportement hérité d'UNIX). D'accord, ces flags ne sont pas très heureux, ils sont même trompeurs.
je ne connais pas très bien ce qu'il se passe dans les systèmes mais sur ma machine les modes read write me paraissent plus clairs les goûts et les couleurs ....
Quand à ton idée d'avoir plusieurs fonctions pour ouvrir un fichier, selon les fonctionnalités qu'on souhaite utiliser, ce n'ést pas forcément une bonne idée. En l'occurrence, à l'époque où la fonction a été conçue, il fallait respecter des contraintes importantes liées à la mémoire et à la puissance des processeurs. Une fonction unique était plus pertinente.
Mais c'est vrai que PHP pourrait fournir une interface plus simple-- Mais il en faudrait un réel usage, ce qui n'est pas le cas.
je dois en conclure que read write dans un fichier est peu utilisé ?
pourtant si un fichier contient des données de taille fixe par exemple des UInt32 ( désolé le type php ne me reviens pas ) les lire et les écrire directement me semble plus efficace qu'une base de donnée , mais il faudrait mesurer
bonne journée
-- mb
In article <4e2bb509$0$7293$426a74cc@news.free.fr>,
Mickael Wolff <mickael.wolff@laposte.net> wrote:
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP.
Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne
argumentation pour que ce soit accepté.
le principe de l'inclusion d'un php par du C m'échappe totalement
ceci dit je n'ai pas besoin d'une puissance extraordinaire
( juste amateur )
mais d'accord , je vais écrire des fct php "singeant" le comportement
dont j'ai l'habitude
> mais il semble que php se soit développé trop vite
Ça n'a rien à voir avec PHP. Comme je l'ai dit, c'est la faute à
POSIX, et même UNIX (j'ai relu le manpage de la fonction open, et
effectivement, c'est un comportement hérité d'UNIX). D'accord, ces flags
ne sont pas très heureux, ils sont même trompeurs.
je ne connais pas très bien ce qu'il se passe dans les systèmes
mais sur ma machine les modes read write me paraissent plus clairs
les goûts et les couleurs ....
Quand à ton idée d'avoir plusieurs fonctions pour ouvrir un fichier,
selon les fonctionnalités qu'on souhaite utiliser, ce n'ést pas
forcément une bonne idée. En l'occurrence, à l'époque où la fonction a
été conçue, il fallait respecter des contraintes importantes liées à la
mémoire et à la puissance des processeurs. Une fonction unique était
plus pertinente.
Mais c'est vrai que PHP pourrait fournir une interface plus simple--
Mais il en faudrait un réel usage, ce qui n'est pas le cas.
je dois en conclure que read write dans un fichier est peu utilisé ?
pourtant si un fichier contient des données de taille fixe
par exemple des UInt32 ( désolé le type php ne me reviens pas )
les lire et les écrire directement me semble plus efficace qu'une base
de donnée , mais il faudrait mesurer
In article <4e2bb509$0$7293$, Mickael Wolff wrote:
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP. Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne argumentation pour que ce soit accepté.
le principe de l'inclusion d'un php par du C m'échappe totalement ceci dit je n'ai pas besoin d'une puissance extraordinaire ( juste amateur )
mais d'accord , je vais écrire des fct php "singeant" le comportement dont j'ai l'habitude
> mais il semble que php se soit développé trop vite
Ça n'a rien à voir avec PHP. Comme je l'ai dit, c'est la faute à POSIX, et même UNIX (j'ai relu le manpage de la fonction open, et effectivement, c'est un comportement hérité d'UNIX). D'accord, ces flags ne sont pas très heureux, ils sont même trompeurs.
je ne connais pas très bien ce qu'il se passe dans les systèmes mais sur ma machine les modes read write me paraissent plus clairs les goûts et les couleurs ....
Quand à ton idée d'avoir plusieurs fonctions pour ouvrir un fichier, selon les fonctionnalités qu'on souhaite utiliser, ce n'ést pas forcément une bonne idée. En l'occurrence, à l'époque où la fonction a été conçue, il fallait respecter des contraintes importantes liées à la mémoire et à la puissance des processeurs. Une fonction unique était plus pertinente.
Mais c'est vrai que PHP pourrait fournir une interface plus simple-- Mais il en faudrait un réel usage, ce qui n'est pas le cas.
je dois en conclure que read write dans un fichier est peu utilisé ?
pourtant si un fichier contient des données de taille fixe par exemple des UInt32 ( désolé le type php ne me reviens pas ) les lire et les écrire directement me semble plus efficace qu'une base de donnée , mais il faudrait mesurer
bonne journée
-- mb
Mickael Wolff
On 07/25/11 19:36, mb wrote:
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP. Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne argumentation pour que ce soit accepté.
le principe de l'inclusion d'un php par du C m'échappe totalement ceci dit je n'ai pas besoin d'une puissance extraordinaire ( juste amateur )
Non, tu m'as mal compris. PHP est écrit en C. Les extensions sont écrites en C. Donc pour que PHP propose par défaut les fonctions que tu penses meilleures, il faut créer un module PHP en C.
je ne connais pas très bien ce qu'il se passe dans les systèmes mais sur ma machine les modes read write me paraissent plus clairs les goûts et les couleurs ....
Sauf que ce ne sont pas des fonctions standards. Or PHP est portable et c'est construit autour de standards.
je dois en conclure que read write dans un fichier est peu utilisé ?
Ouvrir un fichier en PHP en mode binaire n'est pas courant.
pourtant si un fichier contient des données de taille fixe par exemple des UInt32 ( désolé le type php ne me reviens pas ) les lire et les écrire directement me semble plus efficace qu'une base de donnée , mais il faudrait mesurer
Comme tu le dis, il faudrait mesurer. Mais accéder directement à un fichier depuis PHP a plusieurs gros inconvenient : - accès concurrent (race conditions) - impossibilité de répartir les charges avec plusieurs front ends efficacement - impossibilité de déporter les IO daccès aux données sur un autre serveur
Bref, la micro-optimisation d'accéder directement à un fichier pour changer un nombre a des effets de bords importants.
On 07/25/11 19:36, mb wrote:
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP.
Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne
argumentation pour que ce soit accepté.
le principe de l'inclusion d'un php par du C m'échappe totalement
ceci dit je n'ai pas besoin d'une puissance extraordinaire
( juste amateur )
Non, tu m'as mal compris. PHP est écrit en C. Les extensions sont
écrites en C. Donc pour que PHP propose par défaut les fonctions que tu
penses meilleures, il faut créer un module PHP en C.
je ne connais pas très bien ce qu'il se passe dans les systèmes
mais sur ma machine les modes read write me paraissent plus clairs
les goûts et les couleurs ....
Sauf que ce ne sont pas des fonctions standards. Or PHP est portable
et c'est construit autour de standards.
je dois en conclure que read write dans un fichier est peu utilisé ?
Ouvrir un fichier en PHP en mode binaire n'est pas courant.
pourtant si un fichier contient des données de taille fixe
par exemple des UInt32 ( désolé le type php ne me reviens pas )
les lire et les écrire directement me semble plus efficace qu'une base
de donnée , mais il faudrait mesurer
Comme tu le dis, il faudrait mesurer. Mais accéder directement à un
fichier depuis PHP a plusieurs gros inconvenient :
- accès concurrent (race conditions)
- impossibilité de répartir les charges avec plusieurs front ends
efficacement
- impossibilité de déporter les IO daccès aux données sur un autre
serveur
Bref, la micro-optimisation d'accéder directement à un fichier pour
changer un nombre a des effets de bords importants.
Si ça suffit à ton besoin, créé ces fonctions dans un fichier PHP. Mais pour l'inclusion dans PHP, faudra le faire en C et avoir une bonne argumentation pour que ce soit accepté.
le principe de l'inclusion d'un php par du C m'échappe totalement ceci dit je n'ai pas besoin d'une puissance extraordinaire ( juste amateur )
Non, tu m'as mal compris. PHP est écrit en C. Les extensions sont écrites en C. Donc pour que PHP propose par défaut les fonctions que tu penses meilleures, il faut créer un module PHP en C.
je ne connais pas très bien ce qu'il se passe dans les systèmes mais sur ma machine les modes read write me paraissent plus clairs les goûts et les couleurs ....
Sauf que ce ne sont pas des fonctions standards. Or PHP est portable et c'est construit autour de standards.
je dois en conclure que read write dans un fichier est peu utilisé ?
Ouvrir un fichier en PHP en mode binaire n'est pas courant.
pourtant si un fichier contient des données de taille fixe par exemple des UInt32 ( désolé le type php ne me reviens pas ) les lire et les écrire directement me semble plus efficace qu'une base de donnée , mais il faudrait mesurer
Comme tu le dis, il faudrait mesurer. Mais accéder directement à un fichier depuis PHP a plusieurs gros inconvenient : - accès concurrent (race conditions) - impossibilité de répartir les charges avec plusieurs front ends efficacement - impossibilité de déporter les IO daccès aux données sur un autre serveur
Bref, la micro-optimisation d'accéder directement à un fichier pour changer un nombre a des effets de bords importants.
mb
In article <4e2e454b$0$16426$, Mickael Wolff wrote:
Non, tu m'as mal compris. PHP est écrit en C. Les extensions sont écrites en C. Donc pour que PHP propose par défaut les fonctions que tu penses meilleures, il faut créer un module PHP en C.
je ne les pense pas meilleures , j'ai juste parlé d'habitude je ne savais pas qu'on pouvait écrire en C des fonctions "personnelles" mais la compilation devrait se faire sur le serveur , pour compatibilité je me trompe ? je doute que mon fai accepte un truc pareil ! et de toutes façons j'en suis incapable
> je ne connais pas très bien ce qu'il se passe dans les systèmes > mais sur ma machine les modes read write me paraissent plus clairs > les goûts et les couleurs ....
Sauf que ce ne sont pas des fonctions standards.
problèmes de portabilité ?
Comme tu le dis, il faudrait mesurer. Mais accéder directement à un fichier depuis PHP a plusieurs gros inconvenient :
- accès concurrent (race conditions)
accès au fichier par plusieurs connexions ? peut-être dis-je une bêtise mais la fonction open ne bloque-t-elle pas l'accès au autres qui attendent le close ?
- impossibilité de répartir les charges avec plusieurs front ends efficacement - impossibilité de déporter les IO daccès aux données sur un autre serveur
ceci est dépasse ma compréhension
Bref, la micro-optimisation d'accéder directement à un fichier pour changer un nombre a des effets de bords importants.
effet de bord ? c'est en relation avec les accès multiples ?
bonne journée
-- mb
In article <4e2e454b$0$16426$426a34cc@news.free.fr>,
Mickael Wolff <mickael.wolff@laposte.net> wrote:
Non, tu m'as mal compris. PHP est écrit en C. Les extensions sont
écrites en C. Donc pour que PHP propose par défaut les fonctions que tu
penses meilleures, il faut créer un module PHP en C.
je ne les pense pas meilleures , j'ai juste parlé d'habitude
je ne savais pas qu'on pouvait écrire en C des fonctions "personnelles"
mais la compilation devrait se faire sur le serveur , pour compatibilité
je me trompe ?
je doute que mon fai accepte un truc pareil ! et de toutes façons j'en
suis incapable
> je ne connais pas très bien ce qu'il se passe dans les systèmes
> mais sur ma machine les modes read write me paraissent plus clairs
> les goûts et les couleurs ....
Sauf que ce ne sont pas des fonctions standards.
problèmes de portabilité ?
Comme tu le dis, il faudrait mesurer. Mais accéder directement à un
fichier depuis PHP a plusieurs gros inconvenient :
- accès concurrent (race conditions)
accès au fichier par plusieurs connexions ?
peut-être dis-je une bêtise mais la fonction open ne bloque-t-elle pas
l'accès au autres qui attendent le close ?
- impossibilité de répartir les charges avec plusieurs front ends
efficacement
- impossibilité de déporter les IO daccès aux données sur un autre
serveur
ceci est dépasse ma compréhension
Bref, la micro-optimisation d'accéder directement à un fichier pour
changer un nombre a des effets de bords importants.
effet de bord ? c'est en relation avec les accès multiples ?
In article <4e2e454b$0$16426$, Mickael Wolff wrote:
Non, tu m'as mal compris. PHP est écrit en C. Les extensions sont écrites en C. Donc pour que PHP propose par défaut les fonctions que tu penses meilleures, il faut créer un module PHP en C.
je ne les pense pas meilleures , j'ai juste parlé d'habitude je ne savais pas qu'on pouvait écrire en C des fonctions "personnelles" mais la compilation devrait se faire sur le serveur , pour compatibilité je me trompe ? je doute que mon fai accepte un truc pareil ! et de toutes façons j'en suis incapable
> je ne connais pas très bien ce qu'il se passe dans les systèmes > mais sur ma machine les modes read write me paraissent plus clairs > les goûts et les couleurs ....
Sauf que ce ne sont pas des fonctions standards.
problèmes de portabilité ?
Comme tu le dis, il faudrait mesurer. Mais accéder directement à un fichier depuis PHP a plusieurs gros inconvenient :
- accès concurrent (race conditions)
accès au fichier par plusieurs connexions ? peut-être dis-je une bêtise mais la fonction open ne bloque-t-elle pas l'accès au autres qui attendent le close ?
- impossibilité de répartir les charges avec plusieurs front ends efficacement - impossibilité de déporter les IO daccès aux données sur un autre serveur
ceci est dépasse ma compréhension
Bref, la micro-optimisation d'accéder directement à un fichier pour changer un nombre a des effets de bords importants.
effet de bord ? c'est en relation avec les accès multiples ?
bonne journée
-- mb
Mickael Wolff
On 07/26/11 15:05, mb wrote:
je ne les pense pas meilleures , j'ai juste parlé d'habitude je ne savais pas qu'on pouvait écrire en C des fonctions "personnelles"
PHP est un logiciel libre, tu peux le modifier comme tu veux. D'ailleurs, c'est très intéressant à lire comme logiciel.
mais la compilation devrait se faire sur le serveur , pour compatibilité je me trompe ?
Pas la compilation, mais le module devra être déployé sur le serveur, évidemment.
- accès concurrent (race conditions)
accès au fichier par plusieurs connexions ? peut-être dis-je une bêtise mais la fonction open ne bloque-t-elle pas l'accès au autres qui attendent le close ?
Ah non. fopen ouvre un fichier, point. Il est impossible d'empêcher un processus concurrent de lire ou écrire un fichier. Tu peux poser un lock sur le fichier avec flock, mais ça suppose que les autres processus respectent la convention que tu adopte.
- impossibilité de déporter les IO daccès aux données sur un autre serveur
ceci est dépasse ma compréhension
C'est un problème de répartition des charges. Sur un serveur Web, la ressource critique et rare sont généralement les entrée-sorties sur le système de fichiers. Ils sont intrinsèquement lents, soumis à des limitations matérielles importante. C'est un gros problème qui est souvent la cause d'effondrement des serveurs.
effet de bord ? c'est en relation avec les accès multiples ?
Oui, c'est une des raisons. L'ensemble de tes accès risquent de bloquer le traitement des requêtes. Mais surtout, rien ne te garanti que ce que tu lis et écrit dans le fichier y sera ou y est toujours.
On 07/26/11 15:05, mb wrote:
je ne les pense pas meilleures , j'ai juste parlé d'habitude
je ne savais pas qu'on pouvait écrire en C des fonctions "personnelles"
PHP est un logiciel libre, tu peux le modifier comme tu veux.
D'ailleurs, c'est très intéressant à lire comme logiciel.
mais la compilation devrait se faire sur le serveur , pour compatibilité
je me trompe ?
Pas la compilation, mais le module devra être déployé sur le serveur,
évidemment.
- accès concurrent (race conditions)
accès au fichier par plusieurs connexions ?
peut-être dis-je une bêtise mais la fonction open ne bloque-t-elle pas
l'accès au autres qui attendent le close ?
Ah non. fopen ouvre un fichier, point. Il est impossible d'empêcher
un processus concurrent de lire ou écrire un fichier. Tu peux poser un
lock sur le fichier avec flock, mais ça suppose que les autres processus
respectent la convention que tu adopte.
- impossibilité de déporter les IO daccès aux données sur un autre
serveur
ceci est dépasse ma compréhension
C'est un problème de répartition des charges. Sur un serveur Web, la
ressource critique et rare sont généralement les entrée-sorties sur le
système de fichiers. Ils sont intrinsèquement lents, soumis à des
limitations matérielles importante. C'est un gros problème qui est
souvent la cause d'effondrement des serveurs.
effet de bord ? c'est en relation avec les accès multiples ?
Oui, c'est une des raisons. L'ensemble de tes accès risquent de
bloquer le traitement des requêtes. Mais surtout, rien ne te garanti que
ce que tu lis et écrit dans le fichier y sera ou y est toujours.
je ne les pense pas meilleures , j'ai juste parlé d'habitude je ne savais pas qu'on pouvait écrire en C des fonctions "personnelles"
PHP est un logiciel libre, tu peux le modifier comme tu veux. D'ailleurs, c'est très intéressant à lire comme logiciel.
mais la compilation devrait se faire sur le serveur , pour compatibilité je me trompe ?
Pas la compilation, mais le module devra être déployé sur le serveur, évidemment.
- accès concurrent (race conditions)
accès au fichier par plusieurs connexions ? peut-être dis-je une bêtise mais la fonction open ne bloque-t-elle pas l'accès au autres qui attendent le close ?
Ah non. fopen ouvre un fichier, point. Il est impossible d'empêcher un processus concurrent de lire ou écrire un fichier. Tu peux poser un lock sur le fichier avec flock, mais ça suppose que les autres processus respectent la convention que tu adopte.
- impossibilité de déporter les IO daccès aux données sur un autre serveur
ceci est dépasse ma compréhension
C'est un problème de répartition des charges. Sur un serveur Web, la ressource critique et rare sont généralement les entrée-sorties sur le système de fichiers. Ils sont intrinsèquement lents, soumis à des limitations matérielles importante. C'est un gros problème qui est souvent la cause d'effondrement des serveurs.
effet de bord ? c'est en relation avec les accès multiples ?
Oui, c'est une des raisons. L'ensemble de tes accès risquent de bloquer le traitement des requêtes. Mais surtout, rien ne te garanti que ce que tu lis et écrit dans le fichier y sera ou y est toujours.
