Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #73275 > unrolled thread
| Started by | Cameron Simpson <cs@zip.com.au> |
|---|---|
| First post | 2014-06-14 15:18 +1000 |
| Last post | 2014-06-14 15:18 +1000 |
| 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.
Re: tempfile.py", line 83, in <module> once_lock = _allocate_lock() thread.error: can't allocat lock Cameron Simpson <cs@zip.com.au> - 2014-06-14 15:18 +1000
| From | Cameron Simpson <cs@zip.com.au> |
|---|---|
| Date | 2014-06-14 15:18 +1000 |
| Subject | Re: tempfile.py", line 83, in <module> once_lock = _allocate_lock() thread.error: can't allocat lock |
| Message-ID | <mailman.11062.1402723125.18130.python-list@python.org> |
On 14Jun2014 01:40, SABARWAL, SHAL <ss3141@att.com> wrote:
>Appreciate any help in resolving/understanding following error.
>Very occasionally get following error. The error occurs once every 20 - 30 days. OS HP-UX 11.11
>
>############### ERROR LISTNG #############################
>sem_init: Device busy
[...]
> once_lock = _allocate_lock()
> thread.error: can't allocate lock
[...]
This looks like (erroneous) reuse of a previously allocated anonymous
semaphore. Have a read of HP-UX's sem_init(2) manual page:
http://condor.depaul.edu/dmumaugh/readings/handouts/CSC343/pthreads_man%20pages/semaphore.txt
This will be the underlying OS interface used to make a Python lock. It takes
as an argument a pointer to a piece of memory to represent the semaphore.
That page says that the error code EBUSY ("Device busy") is issued if:
There are threads currently blocked on the semaphore or there are
outstanding locks held on the semaphore.
I would take this to represent a bug in the python code that manages the
semaphores supporting the Lock objects. It looks like the code reuses a
previous sem_t C object while it is still in use. Since this happens very
rarely for you I would guess this is a race condition not detected in testing.
I guess my first question would be: what release of Python are you running?
Have you considered getting the latest source code for Python ( version 2 or 3
according to what your code is using) and building that? It may be that this
issue has been fixed in a later release of Python than the one currently
installed on your HP-UX box.
Cheers,
Cameron Simpson <cs@zip.com.au>
Back to top | Article view | comp.lang.python
csiph-web