Fabio Erculiani f46922e6ca [equo] text_ui: re-acquiring entropy resources locks after exec() is bad ...

in Entropy Client library functions, we currently check if current
pid equals the one stored inside .using_resources file if lock
cannot be acquired in blocking mode. This is bad because the information
is not 100% reliable. The trick was there in order to allow equo
to exec*() without releasing the file locks. However, there could
be a race between lock and unlock Entropy Client methods that could
cause the former to unlink() a still valid lock file. This happens
now due to the introduction of non-exclusive locking support.
Get rid of all this shit then!

2012-03-14 16:17:18 +01:00

..

equo.py

[entropy.const] drop another global variable, etpConst['packagestmpdir']

2011-10-28 11:37:00 +02:00

revision

Release Entropy 1.0_rc90

2012-03-01 12:06:54 +01:00

text_cache.py

[equo] implement shared Entropy Resources locking where required

2012-02-15 19:36:29 +01:00

text_configuration.py

[equo] implement shared Entropy Resources locking where required

2012-02-15 19:36:29 +01:00

text_query.py

[equo] use blocking mode when acquiring the shared lock

2012-02-15 20:07:33 +01:00

text_repositories.py

[equo] implement shared Entropy Resources locking where required

2012-02-15 19:36:29 +01:00

text_rescue.py

[equo] force digest = "0" when regenerating packages

2012-01-24 20:47:54 +01:00

text_security.py

[entropy] move text_tools module from client/ to entropy package (entropy.cli)

2011-10-18 17:09:48 +02:00

text_smart.py

[entropy.const] drop another global variable, etpConst['packagestmpdir']

2011-10-28 11:37:00 +02:00

text_ugc.py

[equo] use blocking mode when acquiring the shared lock

2012-02-15 20:07:33 +01:00

text_ui.py

[equo] text_ui: re-acquiring entropy resources locks after exec() is bad

2012-03-14 16:17:18 +01:00