[linux-audio-dev] Big Qthread vs. pthread and usleep problem

[Paul Davis]

>1) I tried changing over to Qthreads, but the problem is whenever I
>declare a new clas:

I know nothing about Qt except that it requires a language
preprocessor. 

>2) I am using pthread_create right now (everything works), but since the
>loop within the thread is infinite, it poses as a serious resource hog.
>So, what I decided to do is to add usleep(10000) value which would give
>me 10ms sleep "sessions" in between the counting, since my timer only

You can't "just sleep" for less than 20ms. The system timer has that
resolution (at least, by default on x86; its different on other
architectures and it can be changed at kernel compile time), and it is
what is used to wakeup processes that call sleep/usleep/nanosleep. see
below for more.

>uses two decimal points for subdivisions of the second. But whenever I
>do this and compile the program, the application's timer runs SLOWER, no
>matter what is the usleep value (even if it is 1!), and only speeds up
>to what it is supposed to be when I move/wiggle the mouse over the main
>app's widget, and/or click with the mouse. Why the heck is this
>happening? It is obvious that the usleep() is causing this kind of
>unusual behavior in combination with the qt gui, but why, that is a
>mystery to me. Is there a more elegant way of making the pthread sleep
>using sub-second time values? Can someone explain why is this the case?

its really impossible to answer this without seeing your code, which
won't much sense to me since i don't know Qt.

but i don't understand why you have a thread doing this. my impression
has been that your app deals with audio. if it deals with audio, you
can use the passing of time as marked by i/o to the audio interface to
measure time passing. gettimeofday() or even rdtsc(ll) can be used to
measure the passage of time - i can't see why you need a thread that
keeps checking this. why not check the passage of time when you
actually to need to know?

>It seems almost that due to fact that there are no events coming from
>the mouse/keyboard, the qt-gui app is being bogged down by the
>utilization of usleep. If this is the case, can I somehow force fake
>events onto the gui in order to make sure that the app runs smoothly?
>Changing the pthread priority to SCHED_RR or SCHED_FIFO did not fix this
>problem either.

it would make it worse. SCHED_RR or SCHED_FIFO threads that call
usleep with values *less* than 20ms will busy wait. don't do it.

--p

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«