Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Double trouble

 [1/9] from: sanghabum::aol::com at: 22-Jun-2001 14:29


Can anyone suggest a Rebol method (i.e. as far as possible OS-independent) way of my application detecting if there is already an instance of it running on the machine? If AlreadyRunningOnSameMachine? [Alert "Please close other instance first" Halt ] Even if that instance was launched from/by a different console? --Thanks, --Colin.

 [2/9] from: g:santilli:tiscalinet:it at: 23-Jun-2001 14:35


Hello [Sanghabum--aol--com]! On 22-Giu-01, you wrote: S> Can anyone suggest a Rebol method (i.e. as far as possible S> OS-independent) way of my application detecting if there is S> already an instance of it running on the machine? Just an idea: ; at the start of the script if error? try [make-dir %temp-dir] [ alert "Please close other instance first" halt ] ; rest of the script ; just before quitting... delete %temp-dir (If Windows's TCP stack wasn't completely broken, you could have simply opened a listen port instead...) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [3/9] from: sanghabum:aol at: 23-Jun-2001 17:21


[g--santilli--tiscalinet--it]
> S> Can anyone suggest a Rebol method (i.e. as far as possible > S> OS-independent) way of my application detecting if there is
<<quoted lines omitted: 10>>
> (If Windows's TCP stack wasn't completely broken, you could have > simply opened a listen port instead...)
Hi Gabriele, Thanks for the response. You've given me a pretty good indication that I haven't overlooked an inbuilt Rebol mechanism,--- and you've replicated my original thinking (which was forget about TCP stack; try getting a write lock on a file). I thought "write lock on file" rather than "does directory exist?" as that lets me distinguish three cases: --File doesn't exist: I'm the only instance. --File does exist and I can't write to it: I'm a second instance and must close. --File does exists and I can write to it: I'm the only instance, but an earlier one fell over; so maybe I've got some cleaning up to do. However, I can't find any way of getting Rebol to place a write-lock on a file--I can happily write to the same file from two Rebol instances without getting the error response I need, e.g.: Instance 1: MyPort: open/write/direct make file! %doubleTroubleTest insert myport "blah blah" Instance 2: MyPort: open/write/direct make file! %doubleTroubleTest insert myport "blah blah" Obviously, I can write a locking mechanism based on shared areas of a common file. I can even (I think) make it air tight in race conditions. But I only want to do that if there's no magic setting in a Port (or elsewhere) that gives me a write-lock. I've had a probe around and not found anything. Does anyone know better? --Thanks, --Colin.

 [4/9] from: petr:krenzelok:trz:cz at: 24-Jun-2001 0:52


Hi, I solved the case one month ago. The only thing I found for file locking was tcp server based. I have complete solution for non server based locking. I have the script at my work, so you will have to wait till monday. It works based upon following principle: - you call the function supplied with path to file and file name, e.g. %/C/my-dir/ %my-file.txt. It then tries to get lock on %my-file.sem, on the path given. First thing I do is - I check if %my-file.sem exists. If it does, I try to delete it (because some app could crash and left our semaphore file in "dead" state, placed on hd). If I can't delete the .sem file, I know that someone holds the lock. If I can delete it, I open/new/direct %my-file.sem file. So, in the end - we don't have any mechanism to write-protect file, but we can prevent file from being deleted (if we (or someone else) hold it opened ....) The solution is easy enough to adapt to your conditions ... -pekr-

 [5/9] from: g:santilli:tiscalinet:it at: 24-Jun-2001 12:42


Hello Petr! On 24-Giu-01, you wrote: PK> So, in the end - we don't have any mechanism to write-protect PK> file, but we can prevent file from being deleted (if we (or PK> someone else) hold it opened ....) I'm afraid this is not multiplatform. I would work on the Amiga and Windows but not on Unix, when you CAN deleted a file even if it is locked by someone for writing (I tried and REBOL can delete it even if it is in use by another REBOL process). Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [6/9] from: sanghabum:aol at: 26-Jun-2001 3:27


[petr--krenzelok--trz--cz]:
> I solved the case one month ago. The only thing I found for file locking was > tcp server based. I have complete solution for non server based locking. I > have the script at my work, so you will have to wait till monday.
Hi Petr, Did you forget to post this? I know it's not (as Gabriele points out) multi-platform, but it's likely to solve the problem I have. I suspect a lot of things can't be multi-platform without some encapsulated platform-specific code. If you've got the solution for Windows and someone else has it for UNIX, MAC etc then---with a little bit of exemplary cross-platform co-operation---we can put together an industry-wide solution. Thanks, Colin.

 [7/9] from: petr:krenzelok:trz:cz at: 26-Jun-2001 10:02


[Sanghabum--aol--com] wrote:
> [petr--krenzelok--trz--cz]: > > I solved the case one month ago. The only thing I found for file locking was
<<quoted lines omitted: 3>>
> Did you forget to post this? I know it's not (as Gabriele points out) > multi-platform, but it's likely to solve the problem I have.
OK, so here we go: lock: context [ sem-port-spec: func [path file-name][to-file join to-string path head change find copy file-name "." ".SEM"] locked: copy [] get-lock: func [path file-name][ semaphore: sem-port-spec path file-name ; file doesn't exist, or does exist, but semaphore can be closed (dead one) either not exists? semaphore [ ; store pair of file-name, opened port append locked semaphore append locked open/new/direct semaphore true ][ ; semaphore does exist - is locked or dead one? (possible app crash) either remove-sem-file semaphore [ ; store pair of file-name, opened port append locked semaphore append locked open/new/direct semaphore true ][false] ; can't get lock, sorry ... ] ] close-lock: func [path file-name][ semaphore: sem-port-spec path file-name if found? find locked semaphore [ close select locked semaphore remove remove find locked semaphore ] either remove-sem-file semaphore [true][false] ] remove-sem-file: func [semaphore][either not error? try [delete semaphore][true][false]] ] example: lock/get-lock target-path "file-name.txt" ; will create file-name.sem on 'target-path if not lock/get-lock [print "unable to lock file"] ; should print unable to lock file message ... probe lock/locked ; will show you lock/close-lock target-path "file-name.txt" ; will unlock file ... so, the problem is, that unix will allow you to delete file even if you would own regular lock. A little bit lame imo. -pekr-

 [8/9] from: lmecir:mbox:vol:cz at: 27-Jun-2001 17:48


Hi Pekr,
> lock: context [ > > sem-port-spec: func [path file-name][to-file join to-string path head
change
> find copy file-name "." ".SEM"] > > locked: copy [] > > get-lock: func [path file-name][ > semaphore: sem-port-spec path file-name
It looks to me, that 'semaphore will "leak" to the global context, although you didn't intend that
> ; file doesn't exist, or does exist, but semaphore can be closed
(dead one)
> either not exists? semaphore [ > ; store pair of file-name, opened port > append locked semaphore > append locked open/new/direct semaphore
looks like the lock isn't exclusive, there is a possibility for two concurrent scripts to obtain the semaphore
> true > ][ > ; semaphore does exist - is locked or dead one? (possible app
crash)
> either remove-sem-file semaphore [ > ; store pair of file-name, opened port
<<quoted lines omitted: 17>>
> example: > lock/get-lock target-path "file-name.txt" ; will
create
> file-name.sem on 'target-path > if not lock/get-lock [print "unable to lock file"] ; should
print
> "unable to lock file" message ... > probe lock/locked ;
will show
> you > lock/close-lock target-path "file-name.txt" ; will
unlock file
> ... so, the problem is, that unix will allow you to delete file even if
you would
> own regular lock. A little bit lame imo. > > -pekr- >
I have got an exclusive file-based multiplatform locking mechanism, but it is a part of a larger script and I should rewrite it as stand-alone before it can be presented here...

 [9/9] from: petr:krenzelok:trz:cz at: 27-Jun-2001 20:47


> > get-lock: func [path file-name][ > > semaphore: sem-port-spec path file-name > > It looks to me, that 'semaphore will "leak" to the global context,
although
> you didn't intend that
maybe ....
> ; file doesn't exist, or does exist, but semaphore can be closed > (dead one)
<<quoted lines omitted: 5>>
> looks like the lock isn't exclusive, there is a possibility for two > "concurrent" scripts to obtain the semaphore
there is not imo :-) 'semaphore holds e.g. %/C/my-dir/my-file-name.sem. I store pairs of path + opened port, because Rebol interpreter will lock the file, untill I close the port. And that is imo the only problem - the script scrash - it will prevent another instances of Rebol from deleting the semaphore file, because the interpreter still holds OS locks, untill you quit it ...
> I have got an exclusive file-based multiplatform locking mechanism, but it > is a part of a larger script and I should rewrite it as stand-alone before > it can be presented here...
Great - I would like to see it, especially in regards to Unix, where it does seem to be unressolvable. Even if your app uses proper kernel locking, another one can't do so and hence can delete your file. I don't understand why it is that way ... -pekr-

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted