• (disco)

    Sigh. If only the phone could multitask and switch to its regular phone ability...

    But no, that makes too much sense.

  • (disco)

    Everyone knows that if you hang up the phone multiple times it picks it up again. Not to mention the race conditions that could be happening when hanging up three times at once (but I guess that's why that exception mouth-tape is for).

  • (disco) in reply to Tsaukpaetra

    Can't race conditions cause programs to hang up anyway? <!--it's a joke-->

  • (disco) in reply to LB_
    LB_:
    anyway?
    Well in this case, it would be hanging up the connection to the modem, which (If not given a command) won't automatically hang up.

    I did this recently actually in a call, ended up crashing the System UI, but the call remained connected all throughout a "soft reboot"

  • (disco)

    In the early 2000s ... over the next few decades ... Two years later ...

    TIL that 13 years or less is a few decades.

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    >In the early 2000s ... over the next few decades ... Two years later ...

    TIL that 13 years or less is a few decades.

    An article on The Register a few years back (on the Walkman when Sony finally stopped making them) revealed that "a few" might be a number as large as 31 (the cassette Walkman was launched, then replaced by solid-state MP3 players "a few years later", apparently, provided that "a few" can stretch to reach from 1979 to 2010), so "the next few decades" is potentially three centuries.
  • (disco) 
    while(phone.isConnected)
{
  phone.hangup();
}
  • (disco)

    I recall years ago, when Borland Pascal ruled the world, I had an app that called a library function and the function did nothing. In desperation I tried calling the function twice - exactly the same line of code, cut and pasted onto the very next line. Low and behold, it worked. I got several colleagues to check my results, and they concurred. We added a comment saying "Don't know why we have to call this twice, but apparently we do" and shipped it. Unfortunately I can't recall the exact function.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    Everyone knows that if you hang up the phone multiple times it picks it up again.

    Who is this guy Everyone?

  • (disco) in reply to RobyMcAndrew

    Yea, I have had the same problem, although in my case it is a process of joining a CentOS server to a windows AD (so uses can log in using their windows user names and passwords. For some unknown reason, the first time you run the join script, it fails on the last item, but when you run it again, it works.... (but then again, Windows is involved, and we already knows that the Microsoft way of debugging is 'try again until it works' :-) )

  • (disco) in reply to RobyMcAndrew

    It was called 'CallMe2x()'

    I recall years ago, when Borland Pascal ruled the world, I had an app that called a library function and the function did nothing. In desperation I tried calling the function twice - exactly the same line of code, cut and pasted onto the very next line. Low and behold, it worked. I got several colleagues to check my results, and they concurred. We added a comment saying "Don't know why we have to call this twice, but apparently we do" and shipped it. Unfortunately I can't recall the exact function.

  • (disco)

    If at first you don't succeed, try, try again.

    If at first you don't succeed, then skydiving is definitely not for you. --Stephen Wright

  • (disco)

    Hang on… An article from @Remy without smartass comments or a cornify link?

  • (disco)

    On the first call, the IP stack drops your request because the ARP table is empty for your destination, yet it send a ARP/RARP query anyway. On the second call, the IP stack has received a response for your destination and actually send your packet...

    It is even worse if the call must read an answer from the network... without waiting. On old hardware, the round-trip might have been short enough for the read to get the answer on first call, but with fast computer of today, the answer to the first call is available only during the second call (fast computer, or wider network, from LAN on coaxial to the cloud at the antipod)

    Hey, I did not change any line of code on that system for 30 years... just changed the network, from a small delay to a wider lag.

  • (disco) in reply to RFoxmich

    Call me once, shame on - shame on you. Call me twice - you can't get called again.

  • (disco)
    In the early 2000s, they decided to get ahead of the curve, and started building software to work on mobile devices. At the time, it was risky and uncertain, but over the next few decades, the idea of using commodity mobile phones to run their warehouse management software saved the company piles of money.
    Obviously, we must at least have 2030. :wink:
  • (disco) in reply to RobyMcAndrew
    RobyMcAndrew:
    Don't know why we have to call this twice, but apparently we do

    I think I've had to do something like that a couple of times. At least the one I specifically remember, though, there was a specific, documented reason for it. The hardware was pipelined, and the first attempt to read it returned whatever garbage data happened to be in the pipeline and loaded that data you really wanted into the pipeline; the second read returned the valid data (and loaded it again, with another copy of the valid data — that will be no longer be valid the next time you want to do this).

  • (disco) in reply to RFoxmich

    BP had a bug where if a nested function was called from a newly-loaded segment, and that function called a function with a constant string parameter, and that function was large enough to push the calling segment out of memory, the compiler would not emit the code to make sure the constant segment was still in memory. A second call would often generate the right code. Except for that bug the system was almost bug-free. Good times.

  • (disco) in reply to PWolff
    PWolff:
    Who is this guy Everyone?

    How do you know Everyone is a guy? Everyone is not just anyone, but may be someone and probably isn't nobody.

  • (disco) in reply to Yazeran
    Yazeran:
    the first time you run the join script, it fails on the last item, but when you run it again, it works

    For some reason, the server software I use attempts to join, them immediately leave, and later tries to join again. Sometimes it does this too quickly though, and stays joined (but disabled), so joining again fails, and since it's disabled it can't log in to get its own SID (or something). My situation is backwards: Attempt to join at most One time. If it fails, a complete reboot is required, as the system is then in an unknown state and will forever be confused to the point that it will never join.

    Filed under: Probably should make this a sidebar...

  • (disco) in reply to Vault_Dweller
    Vault_Dweller:
    ``` while(phone.isConnected) { phone.hangup(); } ```

    Fun race condition:

    Phone 1: connect Phone 1: Am I connected? Yes. Phone 1: hangup Phone 2: connect Phone 1: Am I connected? Yes. Phone 1: hangup Phone 2: send data OH WAIT I CAN'T

  • (disco) in reply to dkf

    Hang on… An article from @Remy without smartass comments or a cornify link?

    That's the RWTF.

  • (disco) in reply to RFoxmich

    Yeah, where's the snark? Or did Remy finally get broken?

  • (disco) in reply to LB_
    LB_:
    Can't race conditions cause programs to hang up anyway?

    Oh sure. But not the phone; just the program.

  • (disco)

    Even now, every time I log into Informatica's support portal, the first time I log in I get a session expiry screen, which directs me back to the login form; when I log in again I get into support.

    Also, it doesn't matter how many times I tick the "Remember my email address on this computer" box; it never does.

  • (disco)

    We had a situation like this when trying to connect a VPN through a satellite modem. The modem started in an idle state and when you tried to connect it first had to get into a ready state which took some time. There was no indication like a LCD or LED on the modem as to what state it was in.

    While the modem was getting ready, OpenVPN would time out. In the meantime the modem would enter the ready state, so the connection would succeed on the second attempt.

    Our scripts basically contained connect(); connect(); until we figured out what was wrong and implemented a proper fix.

  • (disco)

    The original programmer clearly based his style on this ancient but reasonably well-known bit of FORTRAN code:

    10 STOP STOP STOP ! IN CASE STILL SKIDDING GOTO 10

  • (disco) in reply to cellocgw
    cellocgw:
    10 STOPSTOPSTOP! IN CASE STILL SKIDDINGGOTO 10

    E_NOT_FORTRAN_CODE

  • (disco)

    Once upon a time, there was a small logistics company that did most of their software development in house. In the early 2000s, they decided to get ahead of the curve, and started building software to work on mobile devices.

    That's the problem right there. Everyone knows that in-house software gets ahead of the curve by switching to "Enterprise" software.

  • (disco) 
    Stop(); Stop(); // I think I have seen this before

    Maybe this:

    http://stackoverflow.com/a/16095658

    UPDATE: I actually found this confirmed in the documentation, which seems to suggest you must call WaitForExit TWICE to be sure it finished

  • (disco) in reply to dse

    A more careful reading of that might suggest that you've got to do:

    while (!process.WaitForExit(someDelay))
{
    /* Empty body for clarity */
}
process.WaitForExit();

    Excuse me, but isn't that a really horrible API? Maybe it's just the naming that's weird, but that pattern just makes my stomach churn.

  • (disco) 
    catch (Exception e) {}

    KILL IT WITH FIRE!

  • (disco) in reply to powerlord
    powerlord:
    > > catch (Exception e) {}

    KILL IT WITH FIRE!

    catch (Exception e) {e.kill(new Fire())}

    The above is the bury it alive variant.

  • (disco) in reply to dkf

    So you need to call it once more AFTER the first time it returns success?

    The only case where I'd expect to see such things are system calls:

    waiting = 1;
while( waiting && waitpid( ... ) )
{
    if( errno != EINTR ) {
        /* real error, handle it */
        break;
    }
}

    waiting will likely exist and potentially be cleared by a signal handler. Not having that extra check there is often a bug.

  • (disco) in reply to george_gonzalez

    BP really need to learn to take better care of their pipelines. Something terrible could happen.

  • (disco) in reply to ben_lubar

    Is allowing the same method call on a single object to affect the state of two completely different things a common idiom in Go?

  • (disco) in reply to Buddy

    More real-world example: a multithreaded database connection pool.

Leave a comment on “Hang On…”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article