[BUG] Sockets aren't playing nice with me

Robert Withers withers at vnet.net
Mon Mar 6 09:35:37 UTC 2000


I'm running a recompiled VM, as it turns out.  I compiled in the
socketAccept code change for BSD-style  accepts that I received from
Lex.  That sounds like it could be the problem though.  

What is even stranger is that the two scripts below seem to reset
something.  Before running the one that is titled "Works", it resolves
as ->

> NetNameResolver addressForName: 'ibm.com'   --> nil
> but
> NetNameResolver addressForName: '204.146.80.99'  --> #(204 146 80 99)

After running the first script, the second script works!  That's goofy,
but it does the trick.  :-)

I'll recompile again and report back.

cheers,
Rob

> 
> ???
> 
> What version of libc is your linux using?
> 
> (my problem had to do with the use of the glibc2 libraries, when I
> recompiled the from sources it uses the older libc and works fine...)
> 
> Cheers,
> John
> 
> Robert Withers wrote:
> >
> > Yes, I'm not holding my breathe on VM threads and we should need them as
> > you said.  I am using the ObjectSocket which is a SocketStream.  I
> > started having the problems again this morning.  In bash, I can resolve
> > localhost -> 127.0.0.1, babylon -> 192.168.1.10, and ibm.com ->
> > 204.146.80.99.  This exercises the hosts file (for the first two) and
> > DNS for the third.  I have a default gateway (192.168.1.7) that traffic
> > is routing to to get to DNS which is out there somewhere.
> >
> > In the attachment I included two scripts, "Works" and "Broken".  It is
> > the NetNameResolver which returns '0.0.0.0' for the 'localhost' name.
> > Other names ('ibm.com') return nil.
> >
> > Lex Spoon wrote:
> > >
> > > Robert Withers <withers at vnet.net> wrote:
> > > > Ok, I see what you are saying.  I'll be patient. It can't be that far
> > > > down the road for multiple vm thread support.
> > > >
> > >
> > > I don't think VM threads are going to happen any time soon.  What some
> > > people have done is made a sort of SocketStream which has regular
> > > blocking commands like #next and #next:.  If you use these instead of
> > > using a Socket directly, then you don't have to explicitly do the waits.
> > >
> > > VM threads make things more complicated, and they don't seem to have a
> > > big advantage.
> > >
> > > > Since I am up at work, I will continue with what I have and help revisit
> > > > this when the timing is better (threads)
> > > >
> > >
> > > Is the lack of VM threads causing you any difficulty?  I bet there is a
> > > way to make it work with the current scheme.
> > >
> > > Lex
> >
> > --
> > --------------------------------------------------
> > Smalltalking by choice.  Isn't it nice to have one!
> >
> >     ---------------------------------------------------------------
> > "Works"
> > |s|
> > Socket initializeNetwork.
> > s := Socket newTCP.
> > s connectTo: (NetNameResolver addressForName: '127.0.0.1') port: 21.
> > s waitForConnectionUntil: Socket standardDeadline.
> > s sendSomeData: (String cr, String cr).
> > 1 to: 10 do: [:i |
> >         s sendSomeData: (String cr, String cr).
> >         [s dataAvailable] whileTrue: [Transcript cr; show: s getData printString]].
> > s destroy.
> >
> > "Broken"
> > |s|
> > Socket initializeNetwork.
> > s := Socket newTCP.
> > s connectTo: (NetNameResolver addressForName: 'localhost') port: 21.
> > s waitForConnectionUntil: Socket standardDeadline.
> > s sendSomeData: (String cr, String cr).
> > 1 to: 10 do: [:i |
> >         s sendSomeData: (String cr, String cr).
> >         [s dataAvailable] whileTrue: [Transcript cr; show: s getData printString]].
> > s destroy.

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!





More information about the Squeak-dev mailing list