4 ms·

The code currently given in the stream is `while [ "$(date)" != "Sat Oct 31 16:00:00 EDT 2015" ]; do \ sleep 1; done` ... so I hope the process wakes up on the

The code currently given in the stream is `while [ "$(date)" != "Sat Oct 31 16:00:00 EDT 2015" ]; do \ sleep 1; done` ... so I hope the process wakes up on the correct millisecond.

udev 11y ago
Almost guaranteed not to, since 1 second sleep.
DanWaterworth 11y ago
How would you know if it did?
- smtddr 11y ago
  You may already have figured this out, but just incase anyone is wondering what the potential problem here is... If it doesn't wake up and run the date command in a certain timeframe then this while loops will run forever. The chances of that happening, while greater than zero, are really small though. It'd be something like the loop checks the time at "15:59:59", doesn't match so it goes to sleep just a few milliseconds before "16:00:00" then wakes up and runs the date command again and hopefully the deities of the CPU clock & scheduling will do this before too many milliseconds go by and the time becomes "16:00:01", at which point the while-loop would be infinite since the exact moment in time it's waiting for is now in the past and cannot occur again. I suspect though, CPU clock ticks are measured in nanoseconds or something smaller than a millisecond so this while-loop shouldn't miss its exit criteria on any modern machine. Also, there's a chance this is just a fancy splash screen or even just a screenshot and a Twitch employee will manually get things started when it's time.
  - dllthomas 11y ago
    "I suspect though, CPU clock ticks are measured in nanoseconds or something smaller than a millisecond so this while-loop shouldn't miss its exit criteria on any modern machine." It's not a busy-wait. What matters is not CPU clock ticks, but how quickly an eligible-to-run program gets scheduled. That's still not going to be terribly long, of course.
udev 11y ago
Many solutions, e.g. make sleep 0.9 sec, i.e. less than period to guarantee entering the critical 1 second span at least once.
- jerf 11y ago
  Even if you set the interval to the minimum possible, there is no upper bound on how long it may take to complete, or indeed, any guarantee that it will complete. In this case it doesn't matter, but I point this out because I've seen people trying to use this sort of logic in places where it does matter in the last three months.
  - JonnieCache 11y ago
    You're talking about `sleep` specifically here, right? Or general use of timers/polling for flow control?
    - dllthomas 11y ago
      I think it's "testing equality in timers that aren't guaranteed to fire inside any particular bound".
  - ultramancool 11y ago
    If they'd just switched it to greater than and used a unix timestamp...
    - dllthomas 11y ago
      [ $(date +%s) -ge $(date +%s -d"Sat Oct 31 16:00:00 EDT 2015") ]
boomlinde 11y ago
Why would it have to be the exact millisecond? "$(date)" will have that value for 1 second, assuming the format is correct. There is some very small timespan in which it could fail, but the chances are very much in favor of successfully exiting the loop.
- arjie 11y ago
  `sleep` sleeps for seconds.
  - tlrobinson 11y ago
    And `date` returns a timestamp with seconds precision. `time sh -c 'if [ "$(date)" != "Sat Oct 31 16:00:00 EDT 2015" ]; then sleep 1; fi'` took around 1.010 seconds on my machine, but that includes starting a new shell, so there's probably a much smaller than 1% chance that that particular second will be missed. EDIT: here's a little program to test this: #!/usr/bin/env bash while true; do target=$(expr $(date +%s) + 2) while true; do now=$(date +%s) if [ "$now" != "$target" ]; then if [ "$now" -gt "$target" ]; then echo "FAIL :(" break else sleep 1 fi else echo "OK! :)" break fi sleep 0.1 done done Adjust the "sleep 0.1" to increase or decrease the perecentage of failures. Remove to see that it (almost) never fails.
    - tlrobinson 11y ago
      Accidentally left this running for a few hours... 71 FAIL :( 5747 OK! :) So about 1% failure rate.
      - arjie 11y ago
        Ha ha, nice. Not so bad, then.
      - deleted 11y ago
        [deleted]
jawr 11y ago
Pretty sure it's just a splash screen, but yeah :p
sixothree 11y ago
It's 2015. How is this kind of thing still acceptable?
- tlrobinson 11y ago
  Because this isn't mission critical code, and it will work 99+% of the time. If it doesn't work the author can manually intervene.
- cylon13 11y ago
  It's a splash screen. It's acceptable for the same reason the CSS on your coffee cup doesn't have to parse without error.
deleted 11y ago
[deleted]

The code currently given in the stream is `while [ "$(date)" != "Sat Oct 31 16:00:00 EDT 2015" ]; do \ sleep 1; done` ... so I hope the process wakes up on the correct millisecond.

udev 11y ago

Almost guaranteed not to, since 1 second sleep.

DanWaterworth 11y ago

How would you know if it did?

smtddr 11y ago
You may already have figured this out, but just incase anyone is wondering what the potential problem here is... If it doesn't wake up and run the date command in a certain timeframe then this while loops will run forever. The chances of that happening, while greater than zero, are really small though. It'd be something like the loop checks the time at "15:59:59", doesn't match so it goes to sleep just a few milliseconds before "16:00:00" then wakes up and runs the date command again and hopefully the deities of the CPU clock & scheduling will do this before too many milliseconds go by and the time becomes "16:00:01", at which point the while-loop would be infinite since the exact moment in time it's waiting for is now in the past and cannot occur again. I suspect though, CPU clock ticks are measured in nanoseconds or something smaller than a millisecond so this while-loop shouldn't miss its exit criteria on any modern machine. Also, there's a chance this is just a fancy splash screen or even just a screenshot and a Twitch employee will manually get things started when it's time.
- dllthomas 11y ago
  "I suspect though, CPU clock ticks are measured in nanoseconds or something smaller than a millisecond so this while-loop shouldn't miss its exit criteria on any modern machine." It's not a busy-wait. What matters is not CPU clock ticks, but how quickly an eligible-to-run program gets scheduled. That's still not going to be terribly long, of course.

udev 11y ago

Many solutions, e.g. make sleep 0.9 sec, i.e. less than period to guarantee entering the critical 1 second span at least once.

jerf 11y ago
Even if you set the interval to the minimum possible, there is no upper bound on how long it may take to complete, or indeed, any guarantee that it will complete. In this case it doesn't matter, but I point this out because I've seen people trying to use this sort of logic in places where it does matter in the last three months.
- JonnieCache 11y ago
  You're talking about `sleep` specifically here, right? Or general use of timers/polling for flow control?
  - dllthomas 11y ago
    I think it's "testing equality in timers that aren't guaranteed to fire inside any particular bound".
- ultramancool 11y ago
  If they'd just switched it to greater than and used a unix timestamp...
  - dllthomas 11y ago
    [ $(date +%s) -ge $(date +%s -d"Sat Oct 31 16:00:00 EDT 2015") ]

boomlinde 11y ago

Why would it have to be the exact millisecond? "$(date)" will have that value for 1 second, assuming the format is correct. There is some very small timespan in which it could fail, but the chances are very much in favor of successfully exiting the loop.

arjie 11y ago
`sleep` sleeps for seconds.
- tlrobinson 11y ago
  And `date` returns a timestamp with seconds precision. `time sh -c 'if [ "$(date)" != "Sat Oct 31 16:00:00 EDT 2015" ]; then sleep 1; fi'` took around 1.010 seconds on my machine, but that includes starting a new shell, so there's probably a much smaller than 1% chance that that particular second will be missed. EDIT: here's a little program to test this: #!/usr/bin/env bash while true; do target=$(expr $(date +%s) + 2) while true; do now=$(date +%s) if [ "$now" != "$target" ]; then if [ "$now" -gt "$target" ]; then echo "FAIL :(" break else sleep 1 fi else echo "OK! :)" break fi sleep 0.1 done done Adjust the "sleep 0.1" to increase or decrease the perecentage of failures. Remove to see that it (almost) never fails.
  - tlrobinson 11y ago
    Accidentally left this running for a few hours... 71 FAIL :( 5747 OK! :) So about 1% failure rate.
    - arjie 11y ago
      Ha ha, nice. Not so bad, then.
    - deleted 11y ago
      [deleted]

jawr 11y ago

Pretty sure it's just a splash screen, but yeah :p

sixothree 11y ago

It's 2015. How is this kind of thing still acceptable?

tlrobinson 11y ago
Because this isn't mission critical code, and it will work 99+% of the time. If it doesn't work the author can manually intervene.
cylon13 11y ago
It's a splash screen. It's acceptable for the same reason the CSS on your coffee cup doesn't have to parse without error.

deleted 11y ago

[deleted]