On Fri, 17 Jul 2009, Marco Bernardi wrote:
Hi,
> Hello Przemyslaw Czerpak,
> I finally found your e-mail address so I re-send this message to you ( I
> posted
> it in comp.lang.xharbour ).
> May you please give a look to it and let me know your opinion ?
> Thank you in advance
> Best regards,
> Marco Bernardi
I'm still available at Harbour devel list <harbour@harbour-project.org>
so you can use it for Harbour related question. I'm setting CC in my
answer to this list - maybe some other users are also interested in it.
> Hello to all.
> I already written about such problem some times ago, but I didn't
> receive answer. Therefore I investigate the problem searching in the
> xHarbour source code and I found how to solve it... but I do not
> understand the reason why Przemyslaw Czerpak write such code in file
> source/rtl/filebuf.c and therefore should be nice to me if somebody
> can send this message to him ... or give to me his e-mail address so I
> can communicate directly with him.
> Problem description
> - This behavior happens only in UNIX/LINUX.
> - This behavior happens only with xHarbour 1.2 and not in xHarbour 1.0
> (that I am using now)
> here is code
>
> function main()
> set exclusive off
> dbcreate("temp",{{"line","C",10,0}})
> use temp new
> append blank
> close all
> // until here code just create a table for the test
> use temp new alias temp1 readonly
> use temp new alias temp2
Here in old [x]Harbour version was very serious problem in POSIX
systems. POSIX locks are recognize by kernel using file i-node and
process ID (PID) - not file handle as DOS/Windows users use to think.
It means that the same file open by single process more then once
with different file handles cannot be synchronized by POSIX locks.
Anyhow in ST application programmers may leave with it and quite
easy adopt his code if necessary. Serious problem is only for MT
code. Anyhow it's only one of possible problems. There is second
one much more serious bound with close() function.
man 2 close
and read what will happen with FCNTL locks when file is closed.
All locks are removed and because kernel recognize them by inode+PID
then close() removes also locks set by different handles if they
point to the same file (remove locks from aliased workareas).
It causes that it was not safe to use the same table in aliased
workareas and then close one of them because such operation was
removing all locks explicitly set by user and also hidden one
used internally for synchronization also from aliased workareas.
When I was added support to MT mode to Harbour I decided to write
simple lock server to resolve both problems. Now when files are
reopen in aliased workarea then existing file descriptor is reused
so later we do not have to execute close() and also we can store
information about locks so we can add internal synchronization
in single process. Anyhow it still does not resolve one possible
situation when file open in readonly mode later is reopen in RW
mode. Current Harbour code refuse such operation and set NETERR().
This code was ported to xHarbour but looks that it does not contain
this modification so xHarbour allows to reuse readonly file handle
in RW request so later RLOCK fails. In POSIX systems it's not possible
to set RW lock using readonly file handles.
> ?rlock()
> wait
> quit
> The function "rlock()" return different value depending wich xHarbour/
> Opereting System is used
> - in Windows it return .T.
> - in Linux using xHarbour 1.0 it return .T.
> - in Linux using xHarbour 1.2 it return .F. . This is strange because
> seems that instead to use parameters used to open the table in this
> workarea, xHarbour use configuration of the workarea temp1
> That is not logic, so I tryed to find the reason why, and I found it
> in file source/rtl/filebuf.c. (In xharbour 1.0 such file was not
> present). The function that generates the "problem" is
> "hb_fileExtOpen" that, when a table is open (only in UNIX/LINUX),
> searches if the table has been already open (using hb_fileFind()) and,
> in this case, do not open the table but use previous Handle (pFile).
> I have modified source code in a way that the hb_findFile() function
> return always NULL so any table open is managed like in xHarbour 1.0
> ( or like in windows ) and everything seems to work.... but I do not
> know if Przemyslaw Czerpak uses such method for any special reason
> (may be MultiThread) and should be better for me to know his opinion.
If you disable file sharing then you will restore the previous problems.
In this case I decided to forbid opening table in RO mode and then opening
the same table in RW mode due to bad interaction with platform dependent
code.
Anyhow if it's important functionality then I can extend HB_FILE structure
and add holder for RO file handle so if such request appears then file
is reopen in RW mode, the new handle replace the old one and the old
one is not closed by moved to new file handle holder. It cannot be closed
because it will cause that all existing locks will be released.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
