[Webkit-unassigned] [Bug 49164] [NRWT] If the http lock fails we shouldn't do any locking

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=49164





--- Comment #4 from Csaba Osztrogonac <ossy at webkit.org>  2010-11-08 09:09:29 PST ---
We catched it:

2010-11-08 08:43:35,744 http_lock.py:125  DEBUG Lock does not created: (<type 'exceptions.OSError'>, OSError(17, 'File exists'), <traceback object at 0x026D7418>)
2010-11-08 08:43:35,744 http_lock.py:132  DEBUG Warning, http locking failed!
2010-11-08 08:43:35,744 dump_render_tree_thread.py:545  DEBUG Starting HTTP server ...

---

It means that _guard_lock_file (WebKit.lock) already exists, because 
it was probably left during previous tries of enabling this feature.

One of you Chromium guys, could you remove WebKit.lock file in tempfile.gettempdir() to make http locking work on Chromium-Win bots? 
- "Chromium Win Release (Tests)" bot on build.webkit.org
- "Webkit Win" bot on http://build.chromium.org/p/chromium.webkit/waterfall

But of course it isn't the perfect way to avoid this problem in the future.

---
in def _create_lock_file(self):
    sequential_guard_lock = os.open(self._guard_lock_file, os.O_CREAT | os.O_EXCL)
---

This kind of locking will always fail when a WebKit.lock is stucked for some reason. (e.g. script crashes before unlinking the lock file) I prefer a similar way as in httpd.pm, which always open the lock file and then try to grab the exclusive lock for it:

while (!(open(SEQUENTIAL_GUARD_LOCK, ">$exclusiveLockFile") && flock(SEQUENTIAL_GUARD_LOCK, LOCK_EX|LOCK_NB))) {}

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.