Who OPENed the file
Earl Grieda
parallel. So far, this hasn't caused any issues, and actually works great.
However, I now want to create a Master Data Base File (MDBF) that will hold
the results from each of the programs that can run in parallel. This raises
the (remote) possibility of two, or more, programs trying to write to the
MDBF at the same time. Since only one program at a time can write to a file
I need to check if the file is open, and if it is wait a second and try
again. Since it shouldn't take more than a few hundred milli-seconds for
each program to write to the file (they will only do this once after all the
results are collected) this shouldn't be a problem.
Anyway, my question is, if "catch" returns a 1 when opening the file (I
assume that if the file is already open then catch returns a 1) is there any
way I can find the PID of which program has it open? This might be
necessary if for some strange reason (stupid programmer bug) the program
hangs and keeps the file open. Then I can kill it and move on.
sleb...@gmail.com
What platform are you on? On Unix, if the /proc filesystem is
implemented. You can always scan through each process's directory in
/proc to figure it out.
Ralf Fassel
| Anyway, my question is, if "catch" returns a 1 when opening the file
| (I assume that if the file is already open then catch returns a 1)
This is not a safe assumption. It might work on windows, but it
definitely fails on Unix-like systems where multiple process can have
the same file open simultaneously. You'll better use some locking
mechanism, see http://mini.net/tcl/593
| is there any way I can find the PID of which program has it open?
| This might be necessary if for some strange reason (stupid
| programmer bug) the program hangs and keeps the file open. Then I
| can kill it and move on.
On some Unixes, there is the 'fuser' program which tells you the
pid(s) of programs using a certain file or device. Don't know for
windows.
HTH
R'
Markus....@web.de
> assume that if the file is already open then catch returns a 1) is there any
> way I can find the PID of which program has it open?
Would you like to reuse a logging framework so that you do not need to
care for the management of write access and cleanup on your own?
Regards,
Markus
Earl Grieda
"Ralf Fassel" <ral...@gmx.de> wrote in message
news:ygavezk...@panther.akutech-local.de...
> * "Earl Grieda" <eASQWER...@VADFWEFyahoo.comical>
> | Anyway, my question is, if "catch" returns a 1 when opening the file
> | (I assume that if the file is already open then catch returns a 1)
>
> This is not a safe assumption. It might work on windows, but it
> definitely fails on Unix-like systems where multiple process can have
> the same file open simultaneously. You'll better use some locking
> mechanism, see http://mini.net/tcl/593
Thanks for the link. Although I haven't started to write this part yet, I
was reading the Welch Tcl book to get an idea what needed to be done and
that is where I got my assumption regarding catch.
Ralf Fassel
| Although I haven't started to write this part yet, I was reading the
| Welch Tcl book to get an idea what needed to be done and that is
| where I got my assumption regarding catch.
Note that you still need 'catch' to deal with other errors when
opening files. You just can't rely on 'open' failing in case someone
else already has the file openend or portable scripts.
R'
sleb...@gmail.com
Yeah, Markus's suggestion is a great work around. Have another program
manage the writing & reading from file. This can be a simple TCP/IP
server. All other programs connect to this server to maintain & query
the master database.
This solves the problem of file access since only one program ever
actually uses the file. This also solves the problem of finding the
process id of crashed programs since it's no longer necessary.
Ralf Fassel
| This solves the problem of file access since only one program ever
| actually uses the file. This also solves the problem of finding the
| process id of crashed programs since it's no longer necessary.
And introduces the problem of people having access to the file who
should have not. Whether this is a problem depends on... well the
problem at hand ;-)
R'
sleb...@gmail.com
In which case the tls package should be used to encrypt & authenticate
connections or use the wide variety of cryptographic functions
available in tcllib to cook up your own authentication & encryption
scheme. You can even refuse connections from unknown ip addresses etc.
Like you said, depends on the problem at hand.