[Python-bugs-list] [ python-Bugs-479981 ] socket failed then compiled with treads

[noreply@sourceforge.net]

Bugs item #479981, was opened at 2001-11-09 05:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470

Category: Threads
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket failed then compiled with treads 

Initial Comment:
Operating System HP-UX 11.0 (64 Bit)
I tried to compile Python 2.1.1 this thread support.
Doing so, the tests 
test_socket and test_asynchat both failed
with "(9, 'Bad file number')"
The test_socket succeds if I compiled python without
threads, so I think it's an thread-problem.
The thread-test istself succeeds.
I think also, that python is correctly linked against
libpthread.
The same Problem occurs this Python 2.2.b1.






----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-12 02:12

Message:
Logged In: NO 

Maybe the failure has to do with gethostbyname-stuff.

according the hpux-manpages theese reentrant interfaces are 
obsolete:
      int gethostent_r(struct hostent *result,
                       struct hostent_data *buffer);
      int gethostbyname_r(const char *name,
                          struct hostent *result,
                          struct hostent_data *buffer);
      int gethostbyaddr_r(const char *addr,
                          int len,
                          int type,
                          struct hostent *result,
                          struct hostent_data *buffer);
      int sethostent_r(int stayopen, struct hostent_data 
*buffer);
      int endhostent_r(struct hostent_data *buffer);

The configure-script has correctly found, that there is only
a gethostbyname, but no gethostbyname_r.

according to the man-pages the call to gethostbyname IS
thread-save:
      struct hostent *gethostent(void);
      struct hostent *gethostbyname(const char *name);
      struct hostent *gethostbyaddr(const char *addr,
                                    int len,
                                    int type);

                    ...


 MULTITHREAD USAGE
           Thread Safe:        Yes
           Cancel Safe:        Yes
           Async-cancel Safe:  No
           Async-signal Safe:  No


Is it a failure to expect the gethostbyname to be not 
thread-save ?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-12 01:29

Message:
Logged In: NO 

the complete compiler line used to link together the python 
binary:
gcc  -Wl,-E -Wl,+s -Wl,+b/mosquito/python/lib/python2.1/lib-
dynload -o python \
Modules/python.o \
libpython2.1.a -lnsl -ldld  -lpthread   -lm  

The compiler I used is gcc 3.01.

I tried it out with the cc from HP - the same effect

After installing the Kernelpatch PHKL_25475, wich supersedes
both PHKL_23842 and PHKL_20942 the failure remains the same

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-09 16:13

Message:
Logged In: YES 
user_id=21627

Can you please also check whether the patches PHKL_23842 (or
equivalent) and/or PHKL_20942.

The patch titles are
PHKL_23842 s700_800 11.00 
  signal,threads,spinlock,scheduler,IDS,q3p 
PHKL_20942  s700_800 11.00 
  signal, nanosleep, spinlock, scheduler

It appears that HP-UX has a number of bugs where signals,
forking, and other aspects of the operating functionality
stop working in the presence of threads. If you don't have
these patches, it would be good if you could try to install
them, and report back whether it changes anything.

Notice that HP apparently has a number of patches with these
titles; they seem to be intended for different machines.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-09 15:51

Message:
Logged In: YES 
user_id=21627

What compiler are you using? Can you please report the
complete compiler line used to link together the python binary?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=479981&group_id=5470