🚀 go-pugleaf

Yep, I had tried the interrupt() call, no luck there either
unfortunately. Without knowing how the Netscape sockets are implemented
(when blocking for input), it's difficult to say what state the thread
is in. I guess there's always stop()...

However there seems to be another solution - using a setSoTimeout() on
the socket seems to make it aware of socket closure during reads. The
timeout can be set to anything nonzero, and the socket reading thread
will suddenly be able to detect when another thread has closed the
socket. Weird huh? Why is this so? The downside of course is having to
deal with the timeout, unless you really do want to have one..


In article <5wc06.162440$3u1.40967621@news3.rdc1.on.home.com>,
  "Tom Hall" <t.hall@home.com> wrote:
> Have you tried calling "interrupt" on the thread after closing the
socket -
> maybe it will take the hint.
>
> Tom
>
> "Evil Doona Bandit" <evildoonabandit@my-deja.com> wrote in message
> news:91ngv3$jep$1@nnrp1.deja.com...
> > Hi Paul, thanks for your response.
> >
> > Unfortunately I'm still having no luck with the first thread
snapping
> > out of it and realising that the socket has actually been closed.
The
> > notify() call was worth a try but Netscape didn't want to cooperate.
> > The thing is, there are no locks being held on the socket object,
and
> > no opportunity for deadlock of any kind - thread 2 closes the socket
> > and returns to being a GUI event handler thread, which leaves the
> > socket reading (blocking) thread as the last remaining user thread.
It
> > is apparently still twiddling its thumbs, waiting for that next
input
> > from the stream. It's pretty weird..
> >
> > Anyway, I thought that this would be a fairly common operation in a
> > client/server situation, so surely others would have encountered
this
> > same issue with Netscape..?
> >
> > Thanks again for the suggestion Paul, I'll keep fiddling around
with it
> > to see what can be done. If you have any more ideas, please let me
know!
> >
> > Thanks,
> >
> > EDB
> >
> > In article <WW1%5.160574$e5.123342@newsfeeds.bigpond.com>,
> >   "Paul Murray" <pmurray@nospam.bigpond.com> wrote:
> > > Try doing a notify() on the socket - may or may not work,
depending
> > on how
> > > blocking is implemented.
> > >
> > > --
> > > --------------------------------------------------------------
> > > Repent! Quit your job! Slack off!
> > > http://www.users.bigpond.com/pmurray
> > > ICQ: 26066755
> > > "Evil Doona Bandit" <evildoonabandit@my-deja.com> wrote in message
> > > news:91hkvn$5t2$1@nnrp1.deja.com...
> > > > Hi,
> > > >
> > > > A small problem that I've encountered with testing an applet in
> > > > Netscape:
> > > >
> > > > Thread 1 blocks on the readObject() call to a (client) Socket's
> > input
> > > > stream.
> > > >
> > > > Thread 2 closes the socket, which should hopefully force Thread
2 to
> > > > throw an IOException, but doesn't. The socket has been closed,
but
> > > > Thread 1 keeps blocking in Netscape v4.70, even though in Sun's
> > > > appletviewer and IE v5.5 it is well behaved and throws the
> > exception.
> > > >
> > > > Has anyone else had the same problem with Netscape? Any ideas? I
> > would
> > > > rather not change the code to put in a Socket timeout, and then
> > have to
> > > > regularly check a flag to see if the socket is due to be closed,
> > etc.
> > > >
> > > > Thanks in advance!
> > > >
> > > > EDB
> > > >
> > > >
> > > > Sent via Deja.com
> > > > http://www.deja.com/
> > >
> > >
> >
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
>


Sent via Deja.com
http://www.deja.com/