Xapian devel - Nov 2015 - Improving Support for Xapian::DB_RETRY_LOCK in Windows(#65)

Hi Olly,

I tried to reach you through Github notifications(email) about this issue
but with no reply, so I thought we could discuss this issue here, I saw
three critical problems in the last patch.


1. Adding code to wrong '#if', i added it to else branch

2. Figuring out 'fd', holding the lock and 'fnm' as in windows
'fnm' differs

Help me out here, and Mention your IRC time ( As I am in India).

Regards,
Abhishek
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xapian.org/pipermail/xapian-devel/attachments/20151105/486241cc/attachment-0002.html>

On Thu, Nov 05, 2015 at 05:28:36PM +0530, Abhishek Singh Kushwah
wrote:
> I tried to reach you through Github notifications(email) about this issue
> but with no reply, so I thought we could discuss this issue here, I saw
> three critical problems in the last patch.
>
> 1. Adding code to wrong '#if', i added it to else branch
The locking code has different conditional cases for each locking
approach, only one of which is actually compiled in to a particular
build.  There are essentially three approaches:

 * Microsoft Windows (including Cygwin)
 * platforms with fcntl() locking (almost everything except MS Windows)
 * flock()
 
We don't use flock() much - pretty much all modern platforms with
flock() have fcntl() locking too, and we use fcntl() in preference.  The
configure script selects it when compiling for DOS with DJGPP, but I
suspect nobody is using that now.

You should only need to change the code in the first case, but your
patch added code to the fcntl() case, which isn't even compiled on the
platform you're trying to change things for.
> 2. Figuring out 'fd', holding the lock and 'fnm' as in
windows 'fnm' differs
`fd` is a file descriptor, but that's only used for fnctl() and flock()
- you want to use `hFile`, which is a WIN32 HANDLE.

`fnm` is just the filename (FileNaMe) of the lock file.
> Help me out here, and Mention your IRC time ( As I am in India).
You might find it simpler to code up the locking as a separate small
program and get that working, then look at slotting it into the existing
code.  It is inherently a fairly well defined unit.

I'm UTC+13 currently.  I don't watch IRC constantly while awake though,
so the usual IRC approach of "ask and be prepared to wait" applies.

Cheers,
    Olly