Opened 12 years ago

Closed 11 years ago

#2171 closed Bug (Fixed)

Inconsistent delay for TCPTimeout option

Reported by: ripdad Owned by: Jpm
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Cc:


A timeout of 1000ms and higher causes a sleep delay.
Delay time depends on TCPTimeout setting.

Opt('TCPTimeout', 1000) = 1 second
Opt('TCPTimeout', 2000) = 2 seconds
Opt('TCPTimeout', 5000) = 5 seconds

Thanks goes to AdmiralAlkex showing timer differences.

Local $iTimer, $Socket, $Server = TCPListen('', 80)
If $Server = -1 Then Exit
Opt('TCPTimeout', 999); <-- set this higher to reproduce the problem
Local $gui = GUICreate('TCPTimeout Test', 400, 250, -1, -1)
While 1
    Switch GUIGetMsg()
        Case -3
    $iTimer = TimerInit()
    $Socket = TCPAccept($Server)
    MsgBox(0, '', TimerDiff($iTimer))


Attachments (0)

Change History (8)

comment:1 Changed 12 years ago by trancexx

The code is meant to produce time delay. The fact that it does it inconsistently is a bug. For example, TCPTimeout 327 should sleep for 327 ms.

comment:2 Changed 12 years ago by trancexx

  • Summary changed from TCPTimeout has sleep delay after 999ms to Inconsistent delay for TCPTimeout option

comment:3 Changed 12 years ago by Valik

It's not inconsistent. For whatever reason the input is in milliseconds but the actual time waited is in seconds. If the underlying API only accepts seconds then AutoIt's design is stupid and shouldn't accept milliseconds when they are going to be converted to seconds internally (with associated precision loss due to storage in an integer). If the underlying API does allow milliseconds then AutoIt's implementation is stupid for converting to seconds.

To test that this is NOT actually inconsistent but rather based on a conversion to seconds simply enter a time like 1750 and you'll see that it waits for 1 second.

Last edited 12 years ago by Valik (previous) (diff)

comment:4 Changed 12 years ago by anonymous

AutoIt's implementation is stupid because it miscalculates delay from user's input.
Underlying API, strictly speaking, allows microsecond precision. API's internal timer is on top of that very precise.
Miscalculation scheme is incredibly strange (stupid maybe even) that it actually made me think it was done on purpose. I even checked logs to see who wrote that part of the code, but it's too old and not logged therefore.

Last edited 12 years ago by trancexx (previous) (diff)

comment:5 Changed 12 years ago by Valik

It wasn't me and it wasn't Jon which pretty much explains it all, really.

comment:6 Changed 11 years ago by Jon

  • Resolution set to Rejected
  • Status changed from new to closed

comment:7 Changed 11 years ago by Jpm

  • Resolution Rejected deleted
  • Status changed from closed to reopened

In fact a bug lead to have only entire second timeout.
subsecond is ignored

comment:8 Changed 11 years ago by Jpm

  • Milestone set to
  • Owner set to Jpm
  • Resolution set to Fixed
  • Status changed from reopened to closed

Fixed by revision [9155] in version:

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The owner will remain Jpm.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.