Date: Thu, 10 Sep 1998 05:37:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eischen@vigrid.com (Daniel Eischen) Cc: eischen@vigrid.com, tlambert@primenet.com, freebsd-current@FreeBSD.ORG, info@highwind.com Subject: Re: Thread Problems Message-ID: <199809100537.WAA07306@usr06.primenet.com> In-Reply-To: <199809100023.UAA19743@pcnet1.pcnet.com> from "Daniel Eischen" at Sep 9, 98 08:23:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The socket option inheritance issue applies to the inheritance of > > user space flags, as well, which I don't think the threads library > > successfully wraps. > > Yes, fcntl is wrapped so that it ORs the users requested flags > with O_NONBLOCK. If the program is setting the O_NONBLOCK then > this will be saved and remembered in the threads file descriptor > table. When the threads library sets the file to non-blocking > it doesn't set the O_NONBLOCK flag in the file descriptor table. > > Look at the code: I know; this is one of the files that was patched by me and Jeremy Allison to bring FreeBSD's pthreads up to Draft 4 compliance. I also did the fcntl( F_DUPFD), dup2(), and open(w+) patches. 8-). > _thread_fd_table[fd]->flags should only have O_NONBLOCK set if the user > application set it so. Regardless, the file was made non-blocking when > it was created with socket(3). The code seems to do the right thing -- > as long as the socket is still non-blocking. Right; this is where I'm not sure about the preservation of flags. > What do you mean by "derivation from another socket"? dup/dup2/fcntl? Yes. And bind, connect, and accept. > Aren't these suppose to preserve the O_NONBLOCK flag? The threads > library preserves the user space flags, but if the O_NONBLOCK flag > isn't set by the application, then it relies on the system call to > preserve the flag. Theor supposed to; however, since I didn't have a problem with that code, even though I was very carefult to fix error returns and the cases I had thought about, the recent discussions of non-inheritance of socket options have me thinking that perhaps I didn't think of all of them (blame me, not Jeremy; he was interested in making ACAP run -- well, I was, but he got tasked with it for admitting familiarity with some of the issues with the compiler caring about whitespace -- it was my obsessive nature that made me go through the rest of the code). > I tried to repeat the reported problem, but couldn't. I had > one thread listening for client connections, a worker thread > (printing a message once a second), and main. The thread > listening for client connections would create a thread to > handle the connection and go back to accepting more connections. > I couldn't make it fail - the worker thread was always spewing > out messages once a second. I even tried using fork to > process each client request that came in - that worked also. We really need to get more information. Effectively, we have the select coming true before the accept call, followed by the accept call blocking, even though the select was true. In theory, this can't happen, even with a blocking fd. This has got to be a code specific problem. Perhaps they made the mistake of the LDAP implementors about number of descriptors, or the meaning of "preemptive", and are engaged in a buzz-loop. 8-(. I just assumed that the person was running -current, and was seeing what he thought he was seeing; on the other hand... > It'd be nice to see a sample program that reproduced the problem. > I can send info@highwind.com my test program if he wants to try > to hack it up to demonstrate the problem. It would be interesting to know what *exact* version of FreeBSD he was running, as well. Also, if this is a Linux program running under emulation, it should not be expected to work... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809100537.WAA07306>