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

Discussion in 'Java' started by Jan Liße, Feb 16, 2004.

  1. Jan Liße

    Jan Liße Guest

    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
    Jan Liße, Feb 16, 2004
    #1
    1. Advertising

  2. Jan Liße

    Ryan Stewart Guest

    "Jan Liße" <> wrote in message
    news:c0q37g$19jcpa$-berlin.de...
    > 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.
    Ryan Stewart, Feb 16, 2004
    #2
    1. Advertising

  3. Jan Liße 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
    John C. Bollinger, Feb 16, 2004
    #3
  4. Jan Liße <> 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.
    Thomas G. Marshall, Feb 18, 2004
    #4
  5. Jan Liße

    Tony Morris Guest

    "Thomas G. Marshall" <>
    wrote in message news:u1CYb.32339$...
    > Jan Liße <> 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
    Tony Morris, Feb 18, 2004
    #5
  6. Jan Liße

    thoff Guest

    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.
    thoff, Feb 18, 2004
    #6
  7. Tony Morris wrote:

    > "Thomas G. Marshall" <>
    > wrote in message news:u1CYb.32339$...
    >
    >>
    >>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.
    Thomas Schodt, Feb 18, 2004
    #7
  8. Jan Liße

    Ryan Stewart Guest

    "Tony Morris" <> wrote in message
    news:c0urnt$dha$...
    > "Thomas G. Marshall"

    <>
    > wrote in message news:u1CYb.32339$...
    > > Jan Liße <> 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.
    Ryan Stewart, Feb 18, 2004
    #8
  9. Tony Morris <> coughed up the following:

    > "Thomas G. Marshall"
    > <> wrote in
    > message news:u1CYb.32339$...


    ....[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
    Thomas G. Marshall, Feb 18, 2004
    #9
  10. Thomas Schodt" <"news04jan"@\"xenoc.demon.co.uk\
    <"news04jan"@\"xenoc.demon.co.uk\"> coughed up the following:

    > Tony Morris wrote:
    >
    >> "Thomas G. Marshall"
    >> <> wrote in
    >> message news:u1CYb.32339$...
    >>
    >>>
    >>> 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 :)
    Thomas G. Marshall, Feb 18, 2004
    #10
  11. 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
    Thomas G. Marshall, Feb 18, 2004
    #11
  12. Jan Liße

    Tony Morris Guest

    "Thomas G. Marshall" <>
    wrote in message news:f9LYb.58650$...
    > Tony Morris <> coughed up the following:
    >
    > > "Thomas G. Marshall"
    > > <> wrote in
    > > message news:u1CYb.32339$...

    >
    > ...[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
    Tony Morris, Feb 18, 2004
    #12
  13. Tony Morris <> coughed up the following:

    > "Thomas G. Marshall"
    > <> wrote in
    > message news:f9LYb.58650$...
    >> Tony Morris <> coughed up the following:
    >>
    >>> "Thomas G. Marshall"
    >>> <> wrote in
    >>> message news:u1CYb.32339$...

    >>
    >> ...[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.
    Thomas G. Marshall, Feb 19, 2004
    #13
  14. Jan Liße

    Tony Morris Guest

    > 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
    Tony Morris, Feb 19, 2004
    #14
  15. Tony Morris <> 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.
    Thomas G. Marshall, Feb 19, 2004
    #15
  16. Jan Liße

    Tony Morris Guest

    "Thomas G. Marshall" <>
    wrote in message news:9m3Zb.62133$...
    > Tony Morris <> 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
    Tony Morris, Feb 19, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas Kuhn
    Replies:
    4
    Views:
    915
    Thomas Kuhn
    Jul 7, 2003
  2. oziris
    Replies:
    5
    Views:
    2,719
  3. Replies:
    1
    Views:
    826
    Gordon Beaton
    Mar 26, 2007
  4. Paul J. Lucas

    Hanging on ServerSocket.accept()

    Paul J. Lucas, Jul 10, 2008, in forum: Java
    Replies:
    5
    Views:
    2,001
  5. Jozza

    ServerSocket accept

    Jozza, Nov 6, 2008, in forum: Java
    Replies:
    1
    Views:
    386
    Knute Johnson
    Nov 6, 2008
Loading...

Share This Page