Hi Christophe,
Firstly I assume this bit of code is going to be running on each of the 80
Pcs, not as some sort of server process. Is this the case?
(1) If so, I think your proposed method is not going give you any of the
protection you expect.
There could be a "window of opportunity" for another process to get in even
though it should not.
The weakness is that two processes could both succeed in "reserving" the
token.
(2) The other problem is the possibility that a program will fail due to an
error yet leave the token in place so that other processes believe it is
locked.
I suspect that you really need to trust file locking, but the problem is I
haven't been able to work out if there is a way to get Rebol to lock files.
I attempted this:
x: open/write/direct/binary %lock-file.dat
and again in another rebol session which did not return an error so it seems
that Rebol appears to opening the file without exclusive write locking.
With them still open I attempted to open the file with Wordpad.exe. Wordpad
did not open the file - complaining that another application had the file
open - correct. To verify I close the opened ports and tried wordpad.exe
again - this time it opened.
So I believe that it would be good if rebol had file locking abilities.
However I found that if you open a file like I did above, and try to rename
it you will cause an error - indicating the file is in use. This was
confirmed when I belatedly read my site :-\ below
http://www.codeconscious.com/rebol/rebol-net.html#Filelocking
This indicates that a good idea might be for the client to open a tcp/ip
connection with a rebol process on the server. This way if the client
process dies, the connection should (?) timeout - thus dealing with problem
(2). I haven't tried it so ...
Hope it helps.
Brett.
----- Original Message -----
From: "CRS - Psy Sel/SPO, COUSSEMENT Christophe, CPN"
<[EMAIL PROTECTED]>
To: "REBOL List (E-mail)" <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 8:39 PM
Subject: [REBOL] Concurrent access to data file
> Hi REBOLians:
>
> I'm confronted with a little but important problem...
>
> I'm using a block structure for storing data on a server.
> 40 PC's -soon 80- could potentialy dump their data on the same time into
one
> single data file on the server.
> Because we using Win NT -which I do not trust for reability-, I use a
system
> of token to insure concurrent access to the file:
>
> <snip>
>
> forever [
> either all [(count<= 20) token?] [
> count: count + 1
> ;--- attempt to reserve token
> if error? err: try [write token-file now (true)][
> disarm err
> return false
> ]
> wait 5 ;--- take delay to be sure token is written
> ;--- try write operations
> answers: load local-file
> either error? err: try [save remote-file append load
> remote-file answers (true)][
> ;--- release token
> delete token-file
> disarm err
> return false
> ][
> ;--- release token
> delete token-file
> delete local-file
> return true
> ]
>
> ][
> return false
> ]
> ]
>
> token?: func [][
> return not exists? rejoin [global-answer-path global-token]
> ]
>
> </snip>
>
> The token is just a text file in this case, and gives the PC the right to
> "talk" to the server.
> The proc checks for the existence of a token on the server, for a maximum
of
> 20 times. If there's no token on the server, it writes its own one, dump
the
> data and release the token.
> Empirically, I had to set a delay of 5 sec to ensure the token is written,
> because of the slow network connection.
>
> Well, my question is not about straight REBOL, but more a matter of
> methodology :
>
> The procedure works, but, as you can imagine, it is not very efficient for
> so many PC working and dumping together.
> How can I achieve a better performence regarding concurrent access in
REBOL
> on WinNT, which can garanty me no data will be lost ?
>
> Best regard,
>
> chr==
>
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
