Threading and TCP server
Jp Calderone
exarkun at intarweb.us
Fri Feb 7 13:13:42 EST 2003
More information about the Python-list mailing list
Fri Feb 7 13:13:42 EST 2003
- Previous message (by thread): Threading and TCP server
- Next message (by thread): Multiple, separated interpreters in a single process
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, Feb 06, 2003 at 08:33:50PM -0800, Ehab Teima wrote: > Jp Calderone <exarkun at intarweb.us> wrote in message news:<mailman.1044555974.4801.python-list at python.org>... > > On Thu, Feb 06, 2003 at 09:17:27AM -0800, Ehab Teima wrote: > > > Hello, > > > > > > [snip - blocking threads block entire server] > > > > At least two options exist: > > > > Extend your use of threads to include whatever sys call (I'm assuming > > os.system()) you're passing commands to. That is, call os.system("sleep > > 60") from a separate thread from the main server. > > > > Use os.popen() or os.openpty() to execute the commands, and then handle > > the resulting file objects asynchronously. > > I am not sure this will work. I am already using os.popen to launch > the process. Also, the whole client request, including the popen call, > is handled on its own thread. In other words, the popen call is handle > within the client thread as well. Therefore, I do not think that > adding another thread for that specific popen call will help. The > problem disappears when I use spawnv with os.P_NOWAIT since it does > not wait for the process to finish. Any other method that waits for > the process, does trap the server. Perhaps I haven't entirely understood your circumstance. To clarify, I was suggesting that os.system() blocks until the executed command is finished, while neither os.popen() nor os.openpty() do. If you are calling either of the latter two methods from a separate thread from where you call accept() and start new threads, there should be no issue. If there is, you may have a locking issue, or something else "minor" that is hanging things up. On the other hand, if you weren't calling os.system() in the first place, the problem may lie elsewhere. > Aside from that, openpty is only available on Unix, the code has to > work on three Unix platforms in addition to Windows. Then I suppose openpty isn't something you'd want to use - on non-POSIX platforms. You are running system-specific commands, though, so it seems that system-specific ways of invoking them makes sense. There are libraries that will take care of this for you, invoking the most appropriate method depending on the platform on which the program is running. > > Stepping back from the specifics and looking at the problem as a whole, > > I'd recommend using something like Twisted - http://www.twistedmatrix.com/ - > > to solve this problem. It handles the process abstraction for you, it > > handles multiplexing clients for you, it does all the socket code, and it > > doesn't even rely on threads. Jp -- There are 10 kinds of people: those who understand binary and those who do not. -- up 53 days, 21:50, 7 users, load average: 0.16, 0.25, 0.22 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-list/attachments/20030207/f8540404/attachment.sig>
- Previous message (by thread): Threading and TCP server
- Next message (by thread): Multiple, separated interpreters in a single process
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list