Si tu veux être robuste, tu fais des écritures type ajout seulement. En cas d'écriture multiple, cela doit être le bordel. J'imagine que le write bas niveau (et non fwrite) doit permettre de faire des écriture atomiques, mais rien ne le garantie formellement (reserfs l'avais mis dans sa doc). Pour des raisons de performance, il vaux mieux, de toute façon, avoir un seul écrivain qui gère les accès multiple au fichier.
Pour un fichier en ajout seulement, le dernier write() sera présent ou absent, c'est la garantit du VFS Linux (cela ne sera pas un truc à moitié). Cela peut être déjà une bonne garantie. fsync() est un mauvaise solution, sans garanti que le disque dur ne fasse pas de cache en écriture. C'est hyper lent, et surtout ce que l'on veut c'est un fdone().
Si tout peut résider en RAM, les lectures ne sont pas vraiment un problème et l'écriture en ajout seulement offre déjà pas mal de garanti.
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 2.
Si tu veux être robuste, tu fais des écritures type ajout seulement. En cas d'écriture multiple, cela doit être le bordel. J'imagine que le write bas niveau (et non fwrite) doit permettre de faire des écriture atomiques, mais rien ne le garantie formellement (reserfs l'avais mis dans sa doc). Pour des raisons de performance, il vaux mieux, de toute façon, avoir un seul écrivain qui gère les accès multiple au fichier.
Pour un fichier en ajout seulement, le dernier write() sera présent ou absent, c'est la garantit du VFS Linux (cela ne sera pas un truc à moitié). Cela peut être déjà une bonne garantie. fsync() est un mauvaise solution, sans garanti que le disque dur ne fasse pas de cache en écriture. C'est hyper lent, et surtout ce que l'on veut c'est un fdone().
Si tout peut résider en RAM, les lectures ne sont pas vraiment un problème et l'écriture en ajout seulement offre déjà pas mal de garanti.
"La première sécurité est la liberté"