It depends on how sleep(3) is implemented really. Usually sleep means approximately one second resolution. If you start adding fractional second sleeps, say 1.5ms is required, you start moving into real time space at which point the kernel API, userland C runtime and all sorts have to change.
Plus there are good reasons not to arbitrarily sleep for sub-second times for the sake of the scheduler. You probably should be using select or other event driven programming models rather than relying on delays.
Fwiw, on recent FreeBSDs nanosleep(2) is the system call, which is what both sleep(3) and sleep(1) use, the former with whole numbers of seconds, and the latter with fractional seconds.
Comments
I'm really curious what the issues were with the proposal to make FreeBSD sleep accept non-integer arguments.
It depends on how sleep(3) is implemented really. Usually sleep means approximately one second resolution. If you start adding fractional second sleeps, say 1.5ms is required, you start moving into real time space at which point the kernel API, userland C runtime and all sorts have to change.
Plus there are good reasons not to arbitrarily sleep for sub-second times for the sake of the scheduler. You probably should be using select or other event driven programming models rather than relying on delays.
Fwiw, on recent FreeBSDs nanosleep(2) is the system call, which is what both sleep(3) and sleep(1) use, the former with whole numbers of seconds, and the latter with fractional seconds.