Thank you Jason,
Comments welcome from all interested parties, before we apply patch.
Paul.
On Sep 10, 2008, at 07:13, Jason Pollock wrote:
PostgreSQL isn't really an option for me here at this point.
I've modified the lock functions to (hopefully) allow linux's flock
semantics.
The code now maintains a list of inode/dev pairs. When a lock
request arrives for an existing inode/dev, it
is forced to wait on a pthread_cond_t.
The change does require that close and fclose be changed to two
functions in the library to maintain the list. Otherwise
the list will get out of sync with the locks. This may not be
viable for the main code base.
I've attached my changes, I would appreciate any comments. Just a
warning - I haven't tested it extensively, just enough to see that
it stops the queue runner from starting a message a second time.
P. A. Bagyenda wrote:
We welcome a solution when one is found! The chickens among us
would, if using Solaris, rather use the PostgreSQL-based queue
storage module instead :)
That brings a number of advantages:
- Queue processing is faster for larger queues, since unlike the
file-based storage which scans the entire queue directory tree on
each run, this one only picks up messages due for processing
- Message archival is built in.
On Sep 04, 2008, at 00:02, Jason Pollock wrote:
Jason Pollock wrote:
I have noticed the same problem. With fcntl locks, the lock
isn't associated with a file descriptor, it's associated with the
file, so if someone opens the file, checks the lock and closes
the file in the same process, the lock is released.
Since it's a required lock, perhaps Solaris mandatory locking
would be a better way to deal with the problem than a dict?
http://sunsite.uakom.sk/sunworldonline/swol-04-1998/swol-04-insidesolaris.html
Closer reading seems to indicate that that won't work either. Nuts.
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
<code_changes.tgz>_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
