Hi Monty,
>T@4 : | | | | | | >lock_external
>T@4 : | | | | | | | >mi_lock_database
>T@4 : | | | | | | | | >my_lock
>T@4 : | | | | | | | | | my: Fd: 9 Op: 0 start: 0 Length: 0 MyFlags: 32
>T@4 : | | | | | | | | <my_lock
>T@4 : | | | | | | | | >my_pread
>T@4 : | | | | | | | | | my: Fd: 9 Seek: 0 Buffer: d2eb24 Count: 176 MyFlags: 4
>T@4 : | | | | | | | | <my_pread
>T@4 : | | | | | | | <mi_lock_database
>At least on Windows op: 0 to means UNLOCK, but I don't how things
under OS/2, 0 means F_RDLCK.
I found the error: when using F_RDLCK, the actual locking code was
locking the range, and making the file access read-only to all
processes (including mysqld).
Removing the read-only flag, fixed locking capabilities.
How is supposed to work F_RDLCK under Unix? because looking at Windows
code, I see that F_RDLCK and F_WRLCK are mapped to LK_NBCLK and
LB_NBRLCK: in the Borland C++ runtime lib, these locks are treated in
the same way, without readonly settings.
Bye,
Yuri Dario
/*
* member of TeamOS/2 - Italy
* http://www.quasarbbs.com/yuri
* http://www.teamos2.it
*/
