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

Reply via email to