But...
I just tested this:

[ self executeAndRetreiveAVeryLongQuery ] forkAt: self userBackgroundPriority.

And it works perfect!
No freeze is observed :)

And parallel operations seems to work too... so out "real-tiny-blocks" 
approuch seems to work.

Cheers,
Esteban

On 2008-08-20 16:00:16 -0300, Esteban Lorenzano <estebanlm at gmail.com> said:

> Hi,
> The driver uses asynchronous calls for comunicating with it's 
> respective engines, as far as the engine allow it, that's one of the 
> powerful features it has.
> This is how we think a query must be:
> 
> 1. call to execute- an external call
> 2. wait for answer (a request to ask if there is already an answer, 
> otherwise, yields for N time)- another external call
> 2.1. loop step 2 until there is an answer.
> 3. retrieve result rows, one by one -an external call each one
> 
> Of course, all of this calls are through FFI, and therefore, 
> blocking... but is better to have many mini-blocks than just one large 
> block.
> 
> That's the theory... right now, the fact is that very large operations 
> on same connection are freezing the image... we are working on that :)
> 
> Cheers,
> Esteban
> 
> On 2008-08-20 15:09:17 -0300, "Ramon Leon" <ramon.leon at allresnet.com> said:
> 
>> 
>>>> So by using FFI it locks the VM and serializes all the
>>> requests through a
>>>> single pipe allowing a long running query to block all other queries
>>>> essentially freezing the VM?
>>> 
>>> Depends on whether OpenDBX (or the driver) support asynchronous mode.
>>> 
>>> Cheers,
>>> - Andreas
>> 
>> But of course, hence the question mark!
>> 
>> Ramon Leon
>> http://onsmalltalk.com