Jonathan Gardner wrote:
> On Oct 25, 2:19 pm, robert <[EMAIL PROTECTED]> wrote:
>> Jonathan Gardner wrote:
>>> On Oct 25, 12:56 pm, robert <[EMAIL PROTECTED]> wrote:
>>>> On a server the binary (red hat) installed python2.4 and also a
>>>> fresh compiled python2.5 spits "sem_post: Invalid argument".
>>>> What is this and how can this solved?
>>>> ...
>>>> Python 2.4.3 (#1, Jun 6 2006, 21:10:41)
>>>> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-54)] on linux2
>>>> ...
>>>> server [~]# uname -a
>>>> Linux server 2.4.34.1-p4-smp-bigmem-JWH #1 SMP Mon Mar 19 03:26:57
>>>> JST 2007 i686 i686 i386 GNU/Linux
>>> Are you sure you have compatible binaries? Or did you install a random
>>> RPM without checking for dependencies?
>> Should be compatible - but I am not sure if the kernel was
>> recompiled on this machine. And at least the fresh ./configure'ed
>> and compiled py2.5, which yields the same problem, should be
>> maximum compatible. Maybe because this machine is a "smp-bigmem" ..
>>
>
> At this point, I would start digging into the error messages
> themselves. Maybe a shout out to the developers of whatever code is
> generating that error message. When you understand under what
> conditions that error message is thrown, perhaps it will yield some
> insight into what python is doing differently than everything else.
>
In the Python2.4 sources just this piece causes the sem_post error
message:
void
PyThread_release_lock(PyThread_type_lock lock)
{
sem_t *thelock = (sem_t *)lock;
int status, error = 0;
dprintf(("PyThread_release_lock(%p) called\n", lock));
status = sem_post(thelock);
CHECK_STATUS("sem_post");
}
=======
ERRORS
The sem_post() function will fail if:
[EINVAL]
The sem does not refer to a valid semaphore.
=======
with EINVAL - to me the only remaining reason is somehow a wrong
sem_t memory layout - in the C compiler header file on this rented
server - though the lock was established ok!?? ...
--
http://mail.python.org/mailman/listinfo/python-list
