openshot.developers team mailing list archive

[Jonathan Thomas <jonathan.oomph@xxxxxxxxx>]

TJ, I think there is a simple answer to all of this.  The lock file needs to
be moved to the ~./openshot/ folder for sure.  However, the lock file is
only used for a very specific purpose.  It is to prevent Nautilus from
launching multiple copies of OpenShot when you open many files at once with
"openshot".  Under any other circumstance, OpenShot will run as multiple
instances just fine.  Only 1 instance needs to write to the lock file.  When
the program starts up, it will compare the pid in the lock file to the
current list of running pids, and replace it if it's not found running.  So,
there is no delete code.

Other than moving the file to its new ~./openshot/ location, I don't think
there is anything we need to do.  Does that make sense?

Thanks,
-Jonathan

On Wed, Aug 26, 2009 at 12:27 PM, TJ <ubuntu@xxxxxxxxxxx> wrote:

> 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.
>
>
>