[Idle-dev] Anticipated changes for Mac OS X

[Michael Williams]

In message <m37kesnma3.fsf@float.attbi.com> kbk@shore.net (Kurt B. Kaiser) writes:
> Michael Williams <michael.williams@st-annes.oxford.ac.uk> writes: 

[running multiple instances on same multi-user machine]
> > ------ second time, different user, different terminal: % ./idle .
> > .  .  Idle socket error: Address already in use, retrying...
> > 
> > Idle socket error: Address already in use, retrying...
> 
> [...]
>  
> > This takes several seconds on our machine (presumably probing
> > ports). Despite the protestations that something is broken it then
> > launches a new instance of idle in the expected way: on the second
> > users terminal. What's the significance of this error message?
> 
> It was intended to inform the user that 8833 was in use and that since
> Python could not rebind it, IDLE would exit.  I'm curious how your
> system managed to bind a new socket or spawn a new handler since the
> handler was configured to only service one request.
> 
> Could you post a
> 
> lsof -i | grep python   or
> netstat | grep python
> 
> to give me some idea of what happened?

Here's the output after the first user (willmsmj) runs it:

[willmsmj@rayleigh:~]$ lsof -i | grep python
python2.2  9242 willmsmj    4u  inet 0x30008ab6a70        0t0  TCP localhost:8833 (LISTEN)
python2.2  9242 willmsmj    5u  inet 0x30001ce9a78        0t0  TCP localhost:8833->localhost:54317 (ESTABLISHED)
python2.2  9243 willmsmj    3u  inet 0x30002d8c0d0        0t0  TCP localhost:54317->localhost:8833 (ESTABLISHED)

And here's after the second user (guest1)
[willmsmj@rayleigh:~]$ lsof -i | grep python
python2.2  9242 willmsmj    4u  inet 0x30008ab6a70        0t0  TCP localhost:8833 (LISTEN)
python2.2  9242 willmsmj    5u  inet 0x30001ce9a78        0t0  TCP localhost:8833->localhost:54317 (ESTABLISHED)
python2.2  9243 willmsmj    3u  inet 0x30002d8c0d0        0t0  TCP localhost:54317->localhost:8833 (ESTABLISHED)
python2.2  9533   guest1    3u  inet 0x30002d8d570        0t0  TCP localhost:54352->localhost:8833 (ESTABLISHED)

netstat | grep python (or grep idle) give's nothing both times. But...

[willmsmj@rayleigh:~]$ netstat | grep 8833
localhost.54317      localhost.8833       32768      0 32768      0 ESTABLISHED
localhost.8833       localhost.54317      32768      0 32768      0 ESTABLISHED
localhost.54352      localhost.8833       32768      0 32768      0 ESTABLISHED
localhost.8833       localhost.54352      32768      0 32768      0 ESTABLISHED

It looks to me like guest1's idle is not guest1's. It's binding to the first
launched (willmsmj's), using a different socket for the other end. This is
probably a bad thing. 

Recall guest1 sees idle on his own display (after a long wait), and can use it
normally (or as far as I've tested normal use). This is in contrast to IDLEfork
0.8.1, which would launch a new (shell I think) window on the first user's
display when a second user ran it. So we're half way there!

But to emphasise, from our point of view, as long as separate users can run 
multiple *instances* on the same machine, we're happy. Our workaround: 
(http://users.ox.ac.uk/~sann1276/python/report/node47.html), which simply 
generates a number other than 8833 for IDLE to talk on and hopes it works seems
far from optimal, stable or secure in a multi-user environment. 
But it is working for us at the moment.

We'll probably stick with IDLEfork 0.8.1 until this is fixed. That wait the
second user sees is too long, and too scary for our students.
-- 
Michael