A little late, but applied. Do test and let me know.
On Dec 09, 2009, at 06:16, Ian Donaldson wrote:
> >Thanks.
>
> > Would you kindly send a unified diff (preferably against CVS)?
>
> I've applied my patch with adjustments for differences in the CVS
> version, however I'm unable to test it; au
Thanks.
Would you kindly send a unified diff (preferably against CVS)?
On Dec 08, 2009, at 08:47, Ian Donaldson wrote:
> This topic has gone quiet and I've not seen any of the patches
> appear in CVS; its been over a year!
>
> I've just applied the patches and some tweaks to the 1.4.0 base
>
Unfortunately, the same true for the version of MBuni I have. I applied the
patch (with a few changes) to my version (roughly a 1.4) and tested with
that.
The patch against the CVS version is attached. This isn't actually tested
(with CVS version) though. If I get the time, I will try get into t
P. A. Bagyenda wrote:
Jason,
Thanks. It would be nice to see a full patch against latest CVS for
this.
As I've said, my version of Mbuni is drastically different from CVS. :)
I'll see what I can do.
On Sep 19, 2008, at 02:16, Jason Pollock wrote:
P. A. Bagyenda wrote:
Thanks for the
Jason,
Thanks. It would be nice to see a full patch against latest CVS for
this.
On Sep 19, 2008, at 02:16, Jason Pollock wrote:
P. A. Bagyenda wrote:
Thanks for the review.
If you would, kindly share a non-destructive patch for further
discussion.
Here are the changes that I applied
P. A. Bagyenda wrote:
Thanks for the review.
If you would, kindly share a non-destructive patch for further
discussion.
Here are the changes that I applied based on the comments.
Index: mms_util.c
===
RCS file: /home/cvs/MBUNI
Christian Theil Have wrote:
I've been testing the patch and it seems to work out allright :-)
A few notes;
#include
must be outside #ifdef SunOS - other systems needs it too
in unlock_and_fclose(FILE *fp)
fclose is only called in #else, I suppose that should have been like for
unlock_and_clos
Thanks for the review.
If you would, kindly share a non-destructive patch for further
discussion.
P.
On Sep 18, 2008, at 17:05, Christian Theil Have wrote:
I've been testing the patch and it seems to work out allright :-)
A few notes;
#include
must be outside #ifdef SunOS - other syste
I've been testing the patch and it seems to work out allright :-)
A few notes;
#include
must be outside #ifdef SunOS - other systems needs it too
in unlock_and_fclose(FILE *fp)
fclose is only called in #else, I suppose that should have been like for
unlock_and_close or we'll run out of filehand
Christian Theil Have wrote:
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
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 code
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 cod
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
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 th
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, pe
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 mandator
16 matches
Mail list logo