On Sun, Apr 14, 2013 at 1:21 AM, Matthew Dempsky <matt...@dempsky.org>wrote:

> On Sat, Apr 13, 2013 at 2:53 PM, Mihai Popescu <mih...@gmail.com> wrote:
> > Can someone give me some hints in this direction, please, what exactly
> > triggers usleep() internaly ?
>
> usleep() doesn't trigger anything, but usleep(1) doesn't mean "sleep
> exactly 1us", it means "sleep at least 1us".  In practice, your
> process is probably sleeping for much longer than that because of the
> scheduler clock's granularity.
>
> Try calling clock_gettime() immediately before and after the usleep()
> to see how long you're actually sleeping.
>

Thank you, Matthew. That was the situation: usleep(1) takes something like
19 ms. This time is enough to transmit 19 bytes, more that enought for my
case. I didn't expected to sleep exactly 1 us, but neither 19 ms. I
replaced usleep() with a long for cycle and depending of the cycling length
the receiving is varying accordingly.
I think there are more friedly ways to accomplish this but for the moment i
will stay with usleep().

Reply via email to