On Mon, Dec 11, 2000 at 05:08:29PM +0100, Stas Bekman wrote:
> > At 22:11 10/12/2000 +0100, Stas Bekman wrote:
> >
> > I don't know whether or not you're correct as I haven't tested this (which
> > I guess is the only way to really know :). I don't much about fd's either,
I tested sharing fds beteen parent & child, but not dbms, and it breaks
as expected. sysseek() in one process alters the internals of the fd,
tripping up the other process if it happens between seek and read.
You'd have to be very careful to use locks and re-seek before each I/O.
If dbm does re-seek, and you are using locks, it should be Ok, I'd
guess. Make sure to get a locker that flushes the fd and the 4k header
before unlocking, though.
> > but one thing that I think could cause trouble is indeed each() and keys(),
> > and this applies to any kind of tied hash, not just dbm tied hashes.
<good explanation snipped>
> Yup, that's exactly what I was talking about without going into details
> :) thanks for expanding on this!
I'm confused: how can one process' internal variables (the attribute set
to 0 in the example snipped above) affect another process'?
If this were the case, then any use of each() in forked children would
be badly broken. What am I missing?
- Barrie
