RFE: No busy cursor in database feature for threaded calls

[quixotik]

Hi,

I'm wondering if there is a particular reason for AbtDbmSystem to set busy cursors when doing threaded calls? It hinders the user experience when doing database calls in a background process.

Regards, Robin

[Diane Engles]

Hi Robin,

Thanks for your request. Since the original developer of AbtDbmSystem isn't available to me, I don't know the motivating factor(s) for the design decision.

Can you describe your requirements for invoking this method from a background process in more detail?

Would it be adequate to have AbtDbmSystem>>execLongDatabaseOperation: do exactly the same thing it does now without setting a busy cursor or do you have other needs?

Regards,

Diane

[quixotik]

Hello Diane,

Thanks for responding.
I guess the solution is open for debate.
My proposal is to not use busy cursors when both "Processor runningInUI" returns false and "AbtDbmSystem preference: #AllCallsThreaded" returns true.
Eliminating the busy cursor altogether might be too intrusive a change and make others unhappy

Regards, Robin

[quixotik]

Sorry, I forgot your question about my requirements.

I've made a rostering application which holds quite a lot of data. Users want the availability of data for a whole year, but usually start working in the current period, so the idea was to collect the data for the other periods in a separate thread, so that they could start working in the meantime.

Regards, Robin

[quixotik]

Hi,

I was also wondering about the setting #AllCallsThreaded.
Right now, I've set this to true, but in UI's this can result in strange behavior.
Therefore I was wondering if it would be possible extend or change these settings, for example by adding #AllUICallsThreaded and #AllNonUICallsThreaded.
Without breaking existing code this could mean that setting #AllCallsThreaded to true/false would also set #AllUICallsThreaded and #AllNonUICallsThreaded to true/false. One could subsequently set any of the two new settings to true/false and get the desired mixed effect. After that it's easy to add sugar methods that performs the right actions.

Regards, Robin

[tc]

Hello,

I found something Rick Trotter wrote, he was a member of the VAST group.

The virtual machine is single-threaded. All Smalltalk Processes share
a single OS thread.

Call-out to native shared libraries can be made on the VM thread or on
an independent thread. When made on an independent (ACO) thread,
the calling Smalltalk process typically blocks (allowing other Smalltalk
processes to continue execution on the VM thread) until the called
procedure completes with a return value.

It is possibly, however, to make such calls and have the calling
Smalltalk process continue execution (on the VM thread) while the
procedure running on the ACO thread runs. The Smalltalk Process can
later poll for a return value, if desired.

Generally, these ACO threads are allocated on-demand and cached in a
pool when not in use by a call-out. It is possible, however, for a
Smalltalk Process to reserve (or "lock") an ACO thread for its exclusive
use. This is neccessary, in particular, when a shared library maintains
thread-specific state across calls and so requires successive calls to
be made on the same thread.

To me, that means one could allocate an OS thread and do background work in that thread. I have never done this with DB calls but thought this might be useful.

--tc

[marten]

Hi,

I'm wondering if there is a particular reason for AbtDbmSystem to set busy cursors when doing threaded calls? It hinders the user experience when doing database calls in a background process.

Regards, Robin

Just a guess - perhaps the designer wanted to make it possible to have a responsive system by using static future calls (which is done on the very low level db API calls). Then at least you may move your windows around - giving the responsive feeling you would expect from a modern Windows proram AND this also needs a busy cursor.

So this design is done for a modern GUI program and not a sophisticated database program with heavy background processing.

Marten