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

> 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.

I meant: our "real-tiny-blocks" approach :)

> 
> 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