|
|
> Wente, Andreas wrote:
> >logger:
> > - get logmessage
> > - while sharememory is full
> > - sleep 10ms <-- The problem
> > - append log to shared memory
> >
> >reciever:
> > - forever
> > - sleep 10ms
> > - lock sharedmemory
> > - copy sharedmemory
> > - unlock sharedmemory
> > - write log to sqlite-db
>
> Your receiver is waiting 10 ms too much.
>
> It shouldn't wait at all if there's data available. But it must not busy-
> wait. Therefore you need a way of being notified immediately whenever
> there's data available, but sleep for as long as you need when there isn't.
>
I don't think so. The sharedmemory could contain up to 1000 Logmessages. And
there are many loggers. So the chance to get a blocking lock is greater when
the receiver reads the sharedmemory as soon as a message is in. So he will read
it in an intervall, fetches all messages and store them in sqlite within one
transaction. doing this for every message will slow things down, I think.
--
Mit freundlichen Grüßen / kind regards,
Andreas Wente
--
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/
|
|