Big Qthread vs. pthread and usleep problem (UPDATE)

[Danny Shumock]

I'm not sure of the particulars of your application but I can provide some 
information about usleep, etc.  usleep puts the entire process to sleep so 
every thread in your application will sleep for the specified interval.  This 
is usually not what you want in a threaded application.  I have in the past 
used a real-time timer and signal handler to make a single thread wait for a 
specified interval.  I put the thread to sleep using  pthread_cond_wait and 
wait for the condition to be signalled in my signal handler which I set to 
the desired time interval.  I used setitimer to set the time interval.  
Actually I found some code lying around on my computer that does this.  You 
may be able to use it to gain some more information...  I will attach the 
relevant files.  To use the class (make a thread wait) declare an instance of 
CScheduler as a static or global variable and then call the wait method in 
the thread that you want to wait.  (only one per process will work from what 
I can see...  if you need more than one thread to wait you'd have to use a 
single thread with CScheduler and have that thread signal the other threads 
possibly using the attached CEvent class -- wait waits for another thread to 
call signal in the CEvent class).

static CScheduler scheduler(10000);	//  signals every 10 sec

int someThreadFunction()
{
    for(;;) {
        //  do something every 10 sec
        scheduler.wait();
    }
}

I hope this helps!

Danny



On Thursday 29 November 2001 07:52 pm, Ivica Bukvic wrote:
> Well, I figured out how to use Qthread, but it seems rather unstable in
> the 2.2 version when it comes to time-critical events, and besides it
> has the same problem with the usleep function. Now the other even more
> funny thing is that the usleep function kept accurate sleep times, but
> somehow they are twice as much, so what I ended up doing is doubling the
> call to update the timer per cycle of the thread, and now the timer is
> back in the working condition. Nonetheless, this is a highly unusual,
> since when I implemented the double call, the gui "laggyness" also
> vanished... go figure :-). If anyone has any idea what the heck is wrong
> with this picture, I'd be greatly thankfull if you shared your knowledge
> regarding this issue wth me! Thanks!
>
> Ivica Bukvic
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<
-------------- next part --------------
A non-text attachment was scrubbed...
Name: temp.tgz
Type: application/x-gzip
Size: 1189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20011129/3feab0b8/attachment.bin>