Hi
I think it looks good :-) I was working on some similar code based on
a dict, which I was still testing out, but your patch is cleaner.
I look forward to trying it out, but I wont have the opportunity to
test it until Monday though.
About changing close and fclose everywhere in the codebase, you could
get around this without having to change the rest the of codebase by
using a few macros , eg.
#ifdef SunOS
#define close(fd) unlock_and_close(fd)
#endif
....
int unlock_and_close(fd) {
#ifdef close(fd)
#undef close(fd)
printf("unlock_and_close do the stuff..\n");
return close(fd);
#define close(fd) unlock_and_close(fd)
#endif
}
and similarly for fclose...
Christian.
On Sep 10, 2008, at 6:35 AM, P. A. Bagyenda wrote:
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
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel
