openshot.developers team mailing list archive

[TJ <ubuntu@xxxxxxxxxxx>]

Currently classes.lock.checkpid() expects the lock file to be in the
same directory as the application.

This won't work for a 'system' install since the user running the
application will rarely have permissions to write there. An alternative
would be to use "/var/lock/openshot/" but again, that could be
problematic in some circumstances.

I'm currently patching check_pid() to deal with this and also another
issue I noticed when looking at the code: on a multi-user system only
one user would be able to run openshot if the same lock directory is
used.

I'm experimenting with this scenario:

1. When check_pid() is called test if there is a "pid.lock" file in the
user's local directory: 

if os.path.exists(os.path.join(os.path.expanduser("~"), ".openshot/pid.lock")) :

2a. If there is copy 'args' to the user's "~/.openshot/queue" file and
then exit:

fp=open(os.path.join(os.path.expanduser("~"), ".openshot/queue",
str(uuid.uuid1())), 'w')

2b. If there isn't, then create the user file "~/.openshot/pid.lock"

I'm not clear yet where the code is that deletes the "pid.lock" file
when the application closes cleanly (I tried a grep for 'pid\.lock' and
only found ), can you point me to it?

On that thought I got to wondering what might happen if the program
crashes leaving the "pid.lock" file behind since it could prevent a new
instance starting.

The obvious solution would be to compare the PID in
"~/.openshot/pid.lock" with the currently running process list - I'm not
sure right now how to get the process list (or check if a PID is
running) from Python though.

The multi-user potential that moving all the user/process temporary
files to "~/.openshot/" allows is quite exciting - it allows for one
powerful PC with hardware-accelerated H.264/MPEG-2/VC-1 decoding (Nvidia
VDPAU/PureVideo HD chipsets) to serve multiple users for rendering
processor-intensive projects who would connect using a remote X-window
client.