Richard Vaughan scribed:
> i agree. looking around this morning it seems that flock() is out of
> style, and fcntl is very portable, so i'll replace it with fcntl.
> before either of you can tell me, i realized last night (i woke from my
> sleep with this in my head) that the fcntl/flock calls require open file
> descriptors, so the unique lock per device won't scale. dammit i'm
> disappointed with linux for the first time in ages! we need that POSIX
> shared sem functionality! i'll use a single fd for the clock device as the
> advisory lock. we'll get more lock collisions, but it'll scale.
no, not really. as i understand it, another advantage to fcntl() (besides
POSIX) is that you can do record locking, more properly called "range
locking." that is, you specify an offset and length in bytes that you
want to lock. i think that we can use a single fd for the whole mmap()ed
area, and have P & S just lock the ranges that they are reading/writing.
of course, locking a particular range could be more expensive than locking
the whole file; we should find that out somehow.
> one thing that occurred to me is to kick off player as a thread inside
> stage. we'd need a thread entry point that works like player's main(). the
> possible name space collisions could make implementing this tedious, but
> swapping data between P & S would be eays peasy. just a thought for the
yeah, then we could use POSIX mutexes. would take a little work though;
maybe for a future release...