How to kill thread which is blocked by Serversocket.accept()?

java-programmer, How to kill thread which is blocked by Serversocket.accept()? Hi;
I have got a network-thread running in the background listening for
connection-attempts.
The thread uses an instance of Serversocket and its accept() method to
listen.
After a certain period of time i want to kill the thread if no connection is
established.
The problem is: the accept-method blocks until someone connects.
Therefore it is not possible for me to use the interrupted-flag and check it
within a loop in my
thread to signalize it to end (the recommended way to kill a thread). I dont
want to use the thread.stop
() method since it is deprecated, but even when i try to use it i can not
kill the thread.
Within my gui thread i tried to use a swing timer, but it doesnt kill the
thread:

timer = new Timer(TEN_SECONDS, new ActionListener() {
public void actionPerformed(ActionEvent evt) {
if (networkThread.isAlive) {
timer.stop();
networkThread.stop();
//...Update the GUI...
}
}

Anybody there who knows a proper way of killing such a blocked thread?

Thanks in advance,
Jan

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? "Jan Li遝" <email***@***.com> wrote in message
news:c0q37g$19jcpa$email***@***.com...
> Hi;
> I have got a network-thread running in the background listening for
> connection-attempts.
> The thread uses an instance of Serversocket and its accept() method to
> listen.
> After a certain period of time i want to kill the thread if no connection
is
> established.
> The problem is: the accept-method blocks until someone connects.
> Therefore it is not possible for me to use the interrupted-flag and check
it
> within a loop in my
> thread to signalize it to end (the recommended way to kill a thread). I
dont
> want to use the thread.stop
> () method since it is deprecated, but even when i try to use it i can not
> kill the thread.
> Within my gui thread i tried to use a swing timer, but it doesnt kill the
> thread:
>
> timer = new Timer(TEN_SECONDS, new ActionListener() {
> public void actionPerformed(ActionEvent evt) {
> if (networkThread.isAlive) {
> timer.stop();
> networkThread.stop();
> //...Update the GUI...
> }
> }
>
> Anybody there who knows a proper way of killing such a blocked thread?
>
> Thanks in advance,
> Jan
>
Close the socket.

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Jan Li遝 wrote:

> Hi;
> I have got a network-thread running in the background listening for
> connection-attempts.
> The thread uses an instance of Serversocket and its accept() method to
> listen.
> After a certain period of time i want to kill the thread if no connection is
> established.
> The problem is: the accept-method blocks until someone connects.
> Therefore it is not possible for me to use the interrupted-flag and check it
> within a loop in my
> thread to signalize it to end (the recommended way to kill a thread). I dont
> want to use the thread.stop
> () method since it is deprecated, but even when i try to use it i can not
> kill the thread.
> Within my gui thread i tried to use a swing timer, but it doesnt kill the
> thread:
>
> timer = new Timer(TEN_SECONDS, new ActionListener() {
> public void actionPerformed(ActionEvent evt) {
> if (networkThread.isAlive) {
> timer.stop();
> networkThread.stop();
> //...Update the GUI...
> }
> }
>
> Anybody there who knows a proper way of killing such a blocked thread?

I think you are going about it the hard way. If you read the API docs
for ServerSocket.accept(), you will see, among other things,

"Throws:
[...]
SocketTimeoutException - if a timeout was previously set with
setSoTimeout and the timeout has been reached."

That seems custom-made for precisely your problem. If you proceed to
read the docs for setSoTimeout then it seems even more so. Before
invoking accept(), then, set a timeout via setSoTimeout, and you
shouldn't need to worry about actively killing the accepting thread.
Moreover, you can trap the SocketTimeoutException and take appropriate
action in the thread that attempted to accept(), where you have
considerably more context with which to write log messages, retry, or
whatever else you might want to do.

John Bollinger
email***@***.com

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Jan Li遝 <email***@***.com> coughed up the following:

> Hi;
> I have got a network-thread running in the background listening for
> connection-attempts.
> The thread uses an instance of Serversocket and its accept() method to
> listen.
> After a certain period of time i want to kill the thread if no
> connection is established.
> The problem is: the accept-method blocks until someone connects.
> Therefore it is not possible for me to use the interrupted-flag and
> check it within a loop in my
> thread to signalize it to end (the recommended way to kill a thread).
> I dont want to use the thread.stop
> () method since it is deprecated, but even when i try to use it i can
> not kill the thread.
> Within my gui thread i tried to use a swing timer, but it doesnt kill
> the thread:
>
> timer = new Timer(TEN_SECONDS, new ActionListener() {
> public void actionPerformed(ActionEvent evt) {
> if (networkThread.isAlive) {
> timer.stop();
> networkThread.stop();
> //...Update the GUI...
> }
> }
>
> Anybody there who knows a proper way of killing such a blocked thread?
>
> Thanks in advance,
> Jan

Perhaps.....

ServerSocket.accept() can throw an IOException. Check to see if one of the
IOExceptions thrown is actually InterruptedIOException (a subclass of
IOException). It's likely that /that/ will be thrown when somewhere else
Thread.interrupt() is called on the thread running the
ServerSocket.accept(). Basically, call accept() while catching all
exceptions. Then externally call theThread.interrupt(), and see if the
accept() unblocks. Perhaps that'd work----it's been a while since I've used
it.

Sorry, I'd have tested this out for you before posting right now, but my
eclipse install just exploded, so I thought it'd help to think aloud.

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? "Thomas G. Marshall" <email***@***.com>
wrote in message news:u1CYb.32339$email***@***.com...
> Jan Li遝 <email***@***.com> coughed up the following:
>
> > Hi;
> > I have got a network-thread running in the background listening for
> > connection-attempts.
> > The thread uses an instance of Serversocket and its accept() method to
> > listen.
> > After a certain period of time i want to kill the thread if no
> > connection is established.
> > The problem is: the accept-method blocks until someone connects.
> > Therefore it is not possible for me to use the interrupted-flag and
> > check it within a loop in my
> > thread to signalize it to end (the recommended way to kill a thread).
> > I dont want to use the thread.stop
> > () method since it is deprecated, but even when i try to use it i can
> > not kill the thread.
> > Within my gui thread i tried to use a swing timer, but it doesnt kill
> > the thread:
> >
> > timer = new Timer(TEN_SECONDS, new ActionListener() {
> > public void actionPerformed(ActionEvent evt) {
> > if (networkThread.isAlive) {
> > timer.stop();
> > networkThread.stop();
> > //...Update the GUI...
> > }
> > }
> >
> > Anybody there who knows a proper way of killing such a blocked thread?
> >
> > Thanks in advance,
> > Jan
>
> Perhaps.....
>
> ServerSocket.accept() can throw an IOException. Check to see if one of
the
> IOExceptions thrown is actually InterruptedIOException (a subclass of
> IOException). It's likely that /that/ will be thrown when somewhere else
> Thread.interrupt() is called on the thread running the
> ServerSocket.accept(). Basically, call accept() while catching all
> exceptions. Then externally call theThread.interrupt(), and see if the
> accept() unblocks. Perhaps that'd work----it's been a while since I've
used
> it.
>
> Sorry, I'd have tested this out for you before posting right now, but my
> eclipse install just exploded, so I thought it'd help to think aloud.
>
>
>

InterruptedException is not a subclass of IOException, which blows your
whole theory.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? The way i've done it before is to:
1. set an is exit flag to true
2. check the exit flag after accept
3. have another thread make a connection so accept unblocks

Not sure if this is the most elegant java approach,
but it works.

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Tony Morris wrote:

> "Thomas G. Marshall" <email***@***.com>
> wrote in message news:u1CYb.32339$email***@***.com...
>
>>
>>Perhaps.....
>>
>>ServerSocket.accept() can throw an IOException. Check to see if the
>>IOException thrown is actually InterruptedIOException (a subclass of
>>IOException). It's likely that /that/ will be thrown when somewhere else
>>Thread.interrupt() is called on the thread running the
>>ServerSocket.accept(). Basically, call accept() while catching all
>>exceptions. Then externally call theThread.interrupt(), and see if the
>>accept() unblocks. Perhaps that'd work----it's been a while since I've
>>used it.
>>
>>Sorry, I'd have tested this out for you before posting right now, but my
>>eclipse install just exploded, so I thought it'd help to think aloud.
>
> InterruptedException is not a subclass of IOException, which blows your
> whole theory.

I coded something like this recently, it took me a while to notice that
InterruptedException != InterruptedIOException

Anyhow, I found that Thread.interrupt() does not interrupt a socket
operation, so I had to use setSoTimeout() to interrupt the operation
periodically and then check Thread.currentThread().interrupted() to see
if another thread had called Thread.interrupt() on us.

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? "Tony Morris" <email***@***.com> wrote in message
news:c0urnt$dha$email***@***.com...
> "Thomas G. Marshall"
<email***@***.com>
> wrote in message news:u1CYb.32339$email***@***.com...
> > Jan Li遝 <email***@***.com> coughed up the following:
> >
> > > Hi;
> > > I have got a network-thread running in the background listening for
> > > connection-attempts.
> > > The thread uses an instance of Serversocket and its accept() method to
> > > listen.
> > > After a certain period of time i want to kill the thread if no
> > > connection is established.
> > > The problem is: the accept-method blocks until someone connects.
> > > Therefore it is not possible for me to use the interrupted-flag and
> > > check it within a loop in my
> > > thread to signalize it to end (the recommended way to kill a thread).
> > > I dont want to use the thread.stop
> > > () method since it is deprecated, but even when i try to use it i can
> > > not kill the thread.
> > > Within my gui thread i tried to use a swing timer, but it doesnt kill
> > > the thread:
> > >
> > > timer = new Timer(TEN_SECONDS, new ActionListener() {
> > > public void actionPerformed(ActionEvent evt) {
> > > if (networkThread.isAlive) {
> > > timer.stop();
> > > networkThread.stop();
> > > //...Update the GUI...
> > > }
> > > }
> > >
> > > Anybody there who knows a proper way of killing such a blocked thread?
> > >
> > > Thanks in advance,
> > > Jan
> >
> > Perhaps.....
> >
> > ServerSocket.accept() can throw an IOException. Check to see if one of
> the
> > IOExceptions thrown is actually InterruptedIOException (a subclass of
> > IOException). It's likely that /that/ will be thrown when somewhere
else
> > Thread.interrupt() is called on the thread running the
> > ServerSocket.accept(). Basically, call accept() while catching all
> > exceptions. Then externally call theThread.interrupt(), and see if the
> > accept() unblocks. Perhaps that'd work----it's been a while since I've
> used
> > it.
> >
> > Sorry, I'd have tested this out for you before posting right now, but my
> > eclipse install just exploded, so I thought it'd help to think aloud.
> >
> >
> >
>
> InterruptedException is not a subclass of IOException, which blows your
> whole theory.
>
Besides which, would Thread.interrupt() even work here? In the docs, it
seems to indicate that interrupt() will only work on I/O operations being
done by classes that implement java.nio.channels.InterruptibleChannel.

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Tony Morris <email***@***.com> coughed up the following:

> "Thomas G. Marshall"
> <email***@***.com> wrote in
> message news:u1CYb.32339$email***@***.com...

...[thwack]...

>> Perhaps.....
>>
>> ServerSocket.accept() can throw an IOException. Check to see if one
>> of the IOExceptions thrown is actually InterruptedIOException (a
>> subclass of IOException). It's likely that /that/ will be thrown
>> when somewhere else Thread.interrupt() is called on the thread
>> running the ServerSocket.accept(). Basically, call accept() while
>> catching all exceptions. Then externally call
>> theThread.interrupt(), and see if the accept() unblocks. Perhaps
>> that'd work----it's been a while since I've used it.
>>
>> Sorry, I'd have tested this out for you before posting right now,
>> but my eclipse install just exploded, so I thought it'd help to
>> think aloud.
>>
>>
>>
>
> InterruptedException is not a subclass of IOException, which blows
> your whole theory.
>
> --
> Tony Morris

It turns out that the accept() is not interruptible from empirical evidence.

BUT regardless, you need to be more careful before you respond
contentiously. I *never* said anything about "InterruptedException". I
said "InterruptedIOException".

java.lang.Object
java.lang.Throwable
java.lang.Exception
java.io.IOException
java.io.InterruptedIOException

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Thomas Schodt" <"news04jan"@\"xenoc.demon.co.uk\
<"news04jan"@\"xenoc.demon.co.uk\"> coughed up the following:

> Tony Morris wrote:
>
>> "Thomas G. Marshall"
>> <email***@***.com> wrote in
>> message news:u1CYb.32339$email***@***.com...
>>
>>>
>>> Perhaps.....
>>>
>>> ServerSocket.accept() can throw an IOException. Check to see if the
>>> IOException thrown is actually InterruptedIOException (a subclass of
>>> IOException). It's likely that /that/ will be thrown when
>>> somewhere else Thread.interrupt() is called on the thread running
>>> the ServerSocket.accept(). Basically, call accept() while catching
>>> all exceptions. Then externally call theThread.interrupt(), and
>>> see if the accept() unblocks. Perhaps that'd work----it's been a
>>> while since I've used it.
>>>
>>> Sorry, I'd have tested this out for you before posting right now,
>>> but my eclipse install just exploded, so I thought it'd help to
>>> think aloud.
>>
>> InterruptedException is not a subclass of IOException, which blows
>> your whole theory.
>
> I coded something like this recently, it took me a while to notice
> that InterruptedException != InterruptedIOException
>
> Anyhow, I found that Thread.interrupt() does not interrupt a socket
> operation, so I had to use setSoTimeout() to interrupt the operation
> periodically and then check Thread.currentThread().interrupted() to
> see
> if another thread had called Thread.interrupt() on us.

Yeah, and that seems like a shame.

Dusting off some of the gears in me noggin, I remember asking an interview
candidate something similar to this back in the ugly 1.0 days. I *thought*
that interrupts worked on it from 1.1 on though....to much dust I suppose :)

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Thomas Schodt" <"news04jan"@\"xenoc.demon.co.uk\
<"news04jan"@\"xenoc.demon.co.uk\"> coughed up the following:

...[rip]...

> Anyhow, I found that Thread.interrupt() does not interrupt a socket
> operation, so I had to use setSoTimeout() to interrupt the operation
> periodically and then check Thread.currentThread().interrupted() to
> see
> if another thread had called Thread.interrupt() on us.

Apparently there *might* be a resolution to this. Perhaps this is what I
remember.

In any case read this:
http://developer.java.sun.com/developer/bugParade/bugs/4107086.html

If you haven't registered, then the contents are here:
----------------[paste]----------------

Bug Id 4107086

Votes 1

Synopsis Thread.interrupt doesn't work on ServerSocket.accept

Category java:classes_net

Reported Against 1.2beta3

Release Fixed 1.2fcs

State Closed, fixed

Related Bugs

Submit Date Jan 27, 1998

Description: With Solaris green threads, Thread.interrupt on a thread that's
waiting in
ServerSocket.accept has no effect. With native threads, the wrong exception
is
thrown: a plain SocketException instead of InterruptedIOException.

With Solaris green threads, Thread.interrupt on a thread that's waiting in
ServerSocket.accept has no effect. With native threads, the wrong exception
is
thrown: a plain SocketException instead of InterruptedIOException. See the
attached test program.

Workaround None.

Evaluation: This was fixed with the thread interrupt changes that went in
for other bugs,
such as 4152799, 4159884, 4160579.
xxxxx@xxxxx 1998-10-22

Your Comments & Work-arounds

Include a link with my name & email

THU AUG 19 03:59 P.M. 1999
mgriffin2

This still seems to be a problem with
JDK-1.2.2-W, native threads, nojit

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? "Thomas G. Marshall" <email***@***.com>
wrote in message news:f9LYb.58650$email***@***.com...
> Tony Morris <email***@***.com> coughed up the following:
>
> > "Thomas G. Marshall"
> > <email***@***.com> wrote in
> > message news:u1CYb.32339$email***@***.com...
>
> ...[thwack]...
>
> >> Perhaps.....
> >>
> >> ServerSocket.accept() can throw an IOException. Check to see if one
> >> of the IOExceptions thrown is actually InterruptedIOException (a
> >> subclass of IOException). It's likely that /that/ will be thrown
> >> when somewhere else Thread.interrupt() is called on the thread
> >> running the ServerSocket.accept(). Basically, call accept() while
> >> catching all exceptions. Then externally call
> >> theThread.interrupt(), and see if the accept() unblocks. Perhaps
> >> that'd work----it's been a while since I've used it.
> >>
> >> Sorry, I'd have tested this out for you before posting right now,
> >> but my eclipse install just exploded, so I thought it'd help to
> >> think aloud.
> >>
> >>
> >>
> >
> > InterruptedException is not a subclass of IOException, which blows
> > your whole theory.
> >
> > --
> > Tony Morris
>
> It turns out that the accept() is not interruptible from empirical
evidence.
>
> BUT regardless, you need to be more careful before you respond
> contentiously. I *never* said anything about "InterruptedException". I
> said "InterruptedIOException".
>
> java.lang.Object
> java.lang.Throwable
> java.lang.Exception
> java.io.IOException
> java.io.InterruptedIOException
>
>
>

There was never any contention intended.
My apologies for the oversight.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Tony Morris <email***@***.com> coughed up the following:

> "Thomas G. Marshall"
> <email***@***.com> wrote in
> message news:f9LYb.58650$email***@***.com...
>> Tony Morris <email***@***.com> coughed up the following:
>>
>>> "Thomas G. Marshall"
>>> <email***@***.com> wrote in
>>> message news:u1CYb.32339$email***@***.com...
>>
>> ...[thwack]...
>>
>>>> Perhaps.....
>>>>
>>>> ServerSocket.accept() can throw an IOException. Check to see if
>>>> one of the IOExceptions thrown is actually InterruptedIOException
>>>> (a subclass of IOException). It's likely that /that/ will be
>>>> thrown when somewhere else Thread.interrupt() is called on the
>>>> thread running the ServerSocket.accept(). Basically, call
>>>> accept() while catching all exceptions. Then externally call
>>>> theThread.interrupt(), and see if the accept() unblocks. Perhaps
>>>> that'd work----it's been a while since I've used it.
>>>>
>>>> Sorry, I'd have tested this out for you before posting right now,
>>>> but my eclipse install just exploded, so I thought it'd help to
>>>> think aloud.
>>>>
>>>>
>>>>
>>>
>>> InterruptedException is not a subclass of IOException, which blows
>>> your whole theory.
>>>
>>> --
>>> Tony Morris
>>
>> It turns out that the accept() is not interruptible from empirical
>> evidence.
>>
>> BUT regardless, you need to be more careful before you respond
>> contentiously. I *never* said anything about
>> "InterruptedException". I said "InterruptedIOException".
>>
>> java.lang.Object
>> java.lang.Throwable
>> java.lang.Exception
>> java.io.IOException
>> java.io.InterruptedIOException
>>
>>
>>
>
> There was never any contention intended.
> My apologies for the oversight.
>
> --
> Tony Morris
> (BInfTech, Cert 3 I.T.)
> Software Engineer
> (2003 VTR1000F)
> Sun Certified Programmer for the Java 2 Platform (1.4)
> Sun Certified Developer for the Java 2 Platform

Nice bike. Is the 2003 red? I have a white 1993 VFR-750F. A distant
cousin twice removed to the vtr.

When deciding which bike to buy in '93, it was between that and a zx-11, the
/then/ bad boy. I bought the VFR for its technology. A single-sided swing
arm that neatly comes down and grabs the wheel from one side. A 90 degree
V4. Gear driven cams that sound spectacular.

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? > Nice bike. Is the 2003 red? I have a white 1993 VFR-750F. A distant
> cousin twice removed to the vtr.
>
> When deciding which bike to buy in '93, it was between that and a zx-11,
the
> /then/ bad boy. I bought the VFR for its technology. A single-sided
swing
> arm that neatly comes down and grabs the wheel from one side. A 90 degree
> V4. Gear driven cams that sound spectacular.
>
>

Yep, it's red.
http://www.xdweb.net/~dibblego/vtr1000/

My girlfriend loves the look of the VFR800, however, she doesn't hold a
licence or the ability to ride a machine of that calibre (1.5 hours riding
experience) - perhaps another day in the future, we will own one.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? Tony Morris <email***@***.com> coughed up the following:

>> Nice bike. Is the 2003 red? I have a white 1993 VFR-750F. A
>> distant cousin twice removed to the vtr.
>>
>> When deciding which bike to buy in '93, it was between that and a
>> zx-11, the /then/ bad boy. I bought the VFR for its technology. A
>> single-sided swing arm that neatly comes down and grabs the wheel
>> from one side. A 90 degree V4. Gear driven cams that sound
>> spectacular.
>>
>>
>
> Yep, it's red.
> http://www.xdweb.net/~dibblego/vtr1000/
>
> My girlfriend loves the look of the VFR800, however, she doesn't hold
> a licence or the ability to ride a machine of that calibre (1.5 hours
> riding experience) - perhaps another day in the future, we will own
> one.

I've never been a believer in the big-bikes-need-experience thing. /Any/
bike will put you in the ground. A larger bike has a distinct advantage:
You are less likely to get that rut-rut-rut engine complaint by not suppling
enough gas in the wrong gear. But you're right in one respect: I was able
to semi-smoothly go from a standstill to riding speed entirely in 5th gear
on the zx-11, without feathering the crap out of the clutch. (!) It's one
of my tests. I can't imagine what would happen if my hand twitched in
5th...

Sorry guys for the OT. I'll stop.

java-programmer >> How to kill thread which is blocked by Serversocket.accept()? "Thomas G. Marshall" <email***@***.com>
wrote in message news:9m3Zb.62133$email***@***.com...
> Tony Morris <email***@***.com> coughed up the following:
>
> >> Nice bike. Is the 2003 red? I have a white 1993 VFR-750F. A
> >> distant cousin twice removed to the vtr.
> >>
> >> When deciding which bike to buy in '93, it was between that and a
> >> zx-11, the /then/ bad boy. I bought the VFR for its technology. A
> >> single-sided swing arm that neatly comes down and grabs the wheel
> >> from one side. A 90 degree V4. Gear driven cams that sound
> >> spectacular.
> >>
> >>
> >
> > Yep, it's red.
> > http://www.xdweb.net/~dibblego/vtr1000/
> >
> > My girlfriend loves the look of the VFR800, however, she doesn't hold
> > a licence or the ability to ride a machine of that calibre (1.5 hours
> > riding experience) - perhaps another day in the future, we will own
> > one.
>
> I've never been a believer in the big-bikes-need-experience thing. /Any/
> bike will put you in the ground. A larger bike has a distinct advantage:
> You are less likely to get that rut-rut-rut engine complaint by not
suppling
> enough gas in the wrong gear. But you're right in one respect: I was able
> to semi-smoothly go from a standstill to riding speed entirely in 5th gear
> on the zx-11, without feathering the crap out of the clutch. (!) It's
one
> of my tests. I can't imagine what would happen if my hand twitched in
> 5th...
>
> Sorry guys for the OT. I'll stop.
>
>

I feel the same way - but the thought of my girlfriend on a 200kg+ bike
tends to put me off a bit.
I grew up on dirt bikes, and I reckon it's the best way to learn, though I
try to be open-minded about alternatives.
In contrast, the thought of my girlfriend getting on a YZ125 brings less
confidence than a VFR800 - too many times, I've seen a learner drop the
clutch at high engine speed only to land on their butt !

It's going to be a slow process, but if she wants a VFR800, I want to be
confident that she's capable, and right now, I'm not.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform