Another weird backtrace related to cover drawing

[Daniel Winter]

On Thursday 24 July 2008 07:59:13 Mark Kretschmann wrote:
>
> Daniel is absolutely correct here. Doing queries in a worker thread is
> a perfect use case for blocking (=synchronous) queries. In fact it's
> the only sane way to use a blocking query, and one where it makes a
> lot of sense.

Glad to hear that. 

There is another use case (not as perfect, as the api could be changed):

Whenever the querymakers get indirect used by using some blocking calls. 

I can only give examples of the collections internal code for that but I 
believe you could find similar things in other parts of Amarok.

An example from the SQL and Nepomuk collcection:

The TrackList Meta::Album::tracks()  method.  That itself is blocking. At the 
momnent both collections are using the BQ to do the needed querys.

They could kick the BQ and do the needed querys in place. But that will be 
still blocking.  Just  because tracks() is designed to be that way also when 
called from the GUI thread,.

Not using the QM there would be possible (in SQL collection easier than in the 
nepomuk one) but in both cases it will lead to unneeded code doublication.

The current way of using BQ there brings some unneded overhead (and the 
crashing problems).

> Using a blocking query should only ever be done from a non-GUI thread,
> and the blocking query should internally just wait() until the result
> is there, but not do any event loop magic (which as we know can have
> disastrous side effects).

Well here you lost me ;-)  

- Why do we need something like the BlockingQuery maker to do sync queries?

Because the QueryMaker are always async

- Why are the QueryMakers always async?

Because we made them that way. They create a worker thread do the query and 
they and emit signals when they have done their work. 

- Can we change the querymakers to also allow sync querys?

YES, WE CAN! 

(quite easy as I already eplained) And I declared that I will make the changes 
to the SQL and NepomukQueryMaker and proposed the API changes.

- Will that solve all our problems with the BQ?

Yes, when the QueryMakers itself can also  be used in a way in which they not 
spawn a new thread and not emit signals in the first place there is no need to 
have a thing like the BQ class which triese to do something wich is async make 
sync again.

- Can we than remove the BQ class?

We could but we also could port it to use the blocking way of using the 
QueryMakers.

- Do I miss something?

probably ;-)


I hope this time I made my point more clear. (or the explanation in this 
question asking way is even  worse and ridiculous)

> We could make it so that it's technically impossible to use a blocking
> query from the GUI thread. This could be achieved quite easily by
> checking the caller's thread ID.

That would be possible. But I do not like it. We should asume that Amarok devs 
are smart people who only use the QMs in a sane way.

Another reason are things like the tracks() or albums() methods of the Meta 
classes.  They are blocking by design (that may be questionable).  So if we 
enforce the blocking querys to only work for non gui threads we should also 
enforce to use tracks() and albums() only in non gui threads.  (maybe we 
should do that?)  They are doing querys as do the querymakers.