Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #88394 > unrolled thread

Re: Lockfile hanling

Started byErvin Hegedüs <airween@gmail.com>
First post2015-03-31 17:58 +0200
Last post2015-03-31 17:58 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Lockfile hanling Ervin Hegedüs <airween@gmail.com> - 2015-03-31 17:58 +0200

#88394 — Re: Lockfile hanling

FromErvin Hegedüs <airween@gmail.com>
Date2015-03-31 17:58 +0200
SubjectRe: Lockfile hanling
Message-ID<mailman.381.1427817460.10327.python-list@python.org>
Hi Matthew,

On Tue, Mar 31, 2015 at 11:50:06AM -0400, Matthew Ruffalo wrote:
> On 2015-03-31 10:50, Ervin Hegedüs wrote:
> > there is an app, written in Python, which stores few bytes of
> > datas in a single file. The application uses threads. Every
> > thread can modify the file, but only one at a time. I'm using a
> > lock file to prevent the multiple access.
> >
> > ...
> >
> > How can I prevent or avoid this issue? What's the correct way to
> > handle the lockfile in Python?
> 
> Hi Ervin-
> 
> If only one instance of the app is running at a given time, and you only
> need to ensure mutual exclusion between its threads, you should probably
> not use a lock *file* for this. I would strongly recommend that you use
> a threading.Lock as per
> https://docs.python.org/2.5/lib/module-threading.html instead of a lock
> file. This will also allow you to avoid a 0.2-second polling loop; a
> call to threading.Lock.acquire() will block until it is released by
> another thread.
> 
> MMR...

thanks, I hope in the next version I can try this :)


a.

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web