From owner-freebsd-stable Fri Mar 30 13:29: 3 2001 Delivered-To: freebsd-stable@freebsd.org Received: from mail01.actzero.com (w194.z208177157.sjc-ca.dsl.cnc.net [208.177.157.194]) by hub.freebsd.org (Postfix) with ESMTP id EF86737B720 for ; Fri, 30 Mar 2001 13:28:58 -0800 (PST) (envelope-from blm@actzero.com) Received: by w194.z208177157.sjc-ca.dsl.cnc.net with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 13:28:50 -0800 Message-ID: From: Brian Matthews To: freebsd-stable@FreeBSD.ORG Subject: RE: Threads vs. blocking sockets Date: Fri, 30 Mar 2001 13:28:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've gotten behind on this thread (no pun intended :-)) so here are replies to a bunch of stuff: | > the implementation of the threading library | > should, hopefully, be irrelevant. | It's certainly not irrelevant. No, in the real world it's not irrelevant, although it should be. And just because it's not irrelevant doesn't mean we shouldn't strive to make it so (I'm talking POSIX-compliant threading libraries here). | It is not correct even in case of single-threaded program. Consider, | for example, a case when waiting on blocking call is interrupted | with signal. Generally if a signal interrupts a call I don't want to restart it. In the few cases I do (usually SIGCHLD), I specify SA_RESTART when catching the signal. In the specific case that lead me to the original problem, it was an XML-RPC client. It bundles up some data and squirts it at a server. Any signal that comes in I want to kill the client, I most definitely *don't* want it retrying the call. | If you rely on sending all data in send() without checking, your code is buggy. It's not my code. :-) It's the standard Python libraries. I suspect you'd have trouble convincing Guido et al. that code that works as expected on most Unix variants, MacOS, and Windows needs to be changed just for FreeBSD. | Linux does not implement threads correctly. I have had so many problems | with the pseudo-threads that Linux uses, it isn't funny. Threading on | Linux is just another name for forking, and causes so many performance | issues as to be useless. I suspect we could argue forever over "correctly" (for one thing, it doesn't screw up blocking sockets. :-)) However, I agree that Linux' implementation of threads, whether "correct" or not, isn't optimal, and is in fact one of the reasons I'm investigating FreeBSD. | There was a bug in Python 1.52 that caused sends to fail on FreeBSD. I wasn't aware of this, however in my case it's not relevant as I'm using Python 2.0, and the equivalent C code exhibits the same problem. | Nice little tidbit for you: | int sendall(int sd, const char * buf, int * len) I'm aware I could write a little function to loop over sends. My argument is that the libc_r wrappers should do so for me. Also, I don't want to have to modify the Python (and probably perl and maybe some other stuff) standard libraries every time I update them. Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message