Hi,
I don't have currently enough free time to read whole your email, but I would
like to suggest you to use semaphore like solution:
sem: open/new %semaphore.sem
->> error? try [delete %semaphore.sem]
== true
You can't delete your semaphore file while OS holds lock on it .... but be
carefull and don't open several instances of 'sem ...
The advantage here is - even if your app crashes, the solution will work,
because OS will free lock it holds upon the file and rebol will succesfully
delete it ... or so I think :-)
Hope this helps,
Cheers,
-pekr-
"CRS - Psy Sel/SPO, COUSSEMENT Christophe, CPN" wrote:
> 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.
