Patches item #1201569, was opened at 2005-05-13 21:03 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-26 20:31 Message: Logged In: YES user_id=1330769 I agree that IDLE must have a no-subprocess mode, since it has its uses. Still, I feel these uses are relatively isoteric, so while the option should exist as a command line option, it shouldn't usually be used by non-developers. On systems without networking trying to use sockets will fail, and IDLE should detect this and fall-back to no-subprocess mode automatically. (Another item on the TODO list...) Well, we could "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as you say, erratic. Also, if a collision happens the listening socket won't recieve a connection, and accept() will timeout. After this we can continue trying other ports. I submitted my implementation as a separate patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-25 22:40 Message: Logged In: YES user_id=149084 There are a couple of reasons: some systems don't have networking installed, and running w/o the subprocess causes the debugger to work slightly differently: it is possible to debug IDLE itself. It is surprising that it was possible to run IDLE in either mode w/o mucking up the code too badly. But there is one major problem: on Windows, it's possible to start more than one listener on a port. I haven't been able to track this down, it's somewhat erratic. Given the problems on Windows with stuck subprocesses, I'm loath to go to multiple instances of IDLE w/o fixing the multiple listener problem with its collisions. I certainly agree with you that it would be very desireable not to use the -n switch in the "edit with IDLE" binding. And I also agree about the efficacy of the subprocess, that's why we went to all the effort on IDLEfork. https://sourceforge.net/tracker/ index.php?func=detail&aid=661363&group_id=9579&atid=309579 Maybe we can get this fixed in 2.6. It's way too risky to attempt it in 2.5 and it's a new feature. Could you add your patch so I can look at it? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-25 16:42 Message: Logged In: YES user_id=1330769 First of all, there is (theoretically) no reason to un IDLE -without- a subprocess. The subprocess is an awesome feature and I feel that it should be the (good, usable, reliable) default. IDLE's "Run Module" option is very handy but its behavior depends on whether or not there is a subprocess. If there is a subprocess it restarts the interpreter every time, which is good! If there is no subprocess it runs the module the first time, and later does nothing (because of Python's import-once mechanism). On windows the Python installer adds "Edit with IDLE" to Explorer's right-click context menu, which is VERY convenient. But this shortcut start IDLE with the -n precisely because of this subprocess issue. So if I want to be able to use Run Module and have the interpreter restart, I have to manually open the file for editting. Yes, it's something I can live with, but it's a serious turn-off for new users. I often teach Python using IDLE. Having IDLE sometimes run with a subprocess and sometimes without confuses new users, so I end up having to explain the subprocess issue very early, and they still get bitten by it a few times. And they also have to manually open files instead of using the "Edit with IDLE" shortcut. Allowing multiple instances, each with a subprocess listening on a different port, seems like the cleanest solution. Whatever socket issues there are, let's get them cleared up! P.S. I've been using this patch for some time, it works pretty well but not 100%. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-18 15:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 07:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 _______________________________________________ Patches mailing list Patches@python.org http://mail.python.org/mailman/listinfo/patches
