A
Ara.T.Howard
rubyists-
i'm developing a system which needs to coordinate some actions against a nfs
mounted filesystem. there are million ways to skin a cat, but one simple way
is to coordinate actions using fcntl locks on nfs files. to that end i wrote
a module that, when included, replaces File#flock with an fcntl (vs flock)
based implimentation (essentially this is missing/flock.c). this works really
well, i've tested in situations with many machines running many multi threaded
process - each competing to update an ordered on nfs disk list - and it's runs
without error for days on end.
next i thought i'd test an nfs mounted pstore, using the replacement locking
mechanism (fcntl). this does not work. rather, it sort of works but
eventually fails with 'Marshal data too short'. i've tried adding a seek to
end of file after the lock is obtained to pstore.rb, but that does not address
the problem.
so my question is this, assuming that my locking mechanism works (which pretty
serious test show that it does) are there known race conditions when many
processes are competing to update a pstore which could result in dirty reads,
partial writes, or the like?
stumped.
-a
--
ATTN: please update your address books with address below!
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| STP :: http://www.ngdc.noaa.gov/stp/
| NGDC :: http://www.ngdc.noaa.gov/
| NESDIS :: http://www.nesdis.noaa.gov/
| NOAA :: http://www.noaa.gov/
| US DOC :: http://www.commerce.gov/
|
| The difference between art and science is that science is what we
| understand well enough to explain to a computer.
| Art is everything else.
| -- Donald Knuth, "Discover"
|
| /bin/sh -c 'for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done'
===============================================================================
i'm developing a system which needs to coordinate some actions against a nfs
mounted filesystem. there are million ways to skin a cat, but one simple way
is to coordinate actions using fcntl locks on nfs files. to that end i wrote
a module that, when included, replaces File#flock with an fcntl (vs flock)
based implimentation (essentially this is missing/flock.c). this works really
well, i've tested in situations with many machines running many multi threaded
process - each competing to update an ordered on nfs disk list - and it's runs
without error for days on end.
next i thought i'd test an nfs mounted pstore, using the replacement locking
mechanism (fcntl). this does not work. rather, it sort of works but
eventually fails with 'Marshal data too short'. i've tried adding a seek to
end of file after the lock is obtained to pstore.rb, but that does not address
the problem.
so my question is this, assuming that my locking mechanism works (which pretty
serious test show that it does) are there known race conditions when many
processes are competing to update a pstore which could result in dirty reads,
partial writes, or the like?
stumped.
-a
--
ATTN: please update your address books with address below!
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| STP :: http://www.ngdc.noaa.gov/stp/
| NGDC :: http://www.ngdc.noaa.gov/
| NESDIS :: http://www.nesdis.noaa.gov/
| NOAA :: http://www.noaa.gov/
| US DOC :: http://www.commerce.gov/
|
| The difference between art and science is that science is what we
| understand well enough to explain to a computer.
| Art is everything else.
| -- Donald Knuth, "Discover"
|
| /bin/sh -c 'for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done'
===============================================================================