just a curiosity - pre emptive threads

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

just a curiosity - pre emptive threads

4D Tech mailing list
IP vars are out. -- OK
IP sets would be out too, but...
How does 4D manage IP sets, that it does not know are IP sets?

I know in more then one place I don't care about a set name, and use an
algorithm to create a set name. So the set name does not exist until
execution. This kind of code could easily be embedded in a method which
otherwise appears to be thread safe. How does/would 4D handle a set
name which was constructed in this manner but was/became an IP set?
Would 4D flag the method as thread unsafe? How would 4D know?

ex:

$Setname := "<>"+TABLE NAME($Some_table_Pointer)+"_"+STRING(Records in
Selection($Some_table_Pointer->))
Create Set(Some_table_Pointer->;$Setname)

I suppose for that matter, how does 4D handle other instances where
text is turned into a variable (Get pointer)?

Chip
---------------
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
Are you doing all this in single user mode?

I think a lot of people don't realize that preemptive threads aren't supported on 4D Remote at all.

> On Jul 11, 2018, at 3:31 PM, Chip Scheide via 4D_Tech <[hidden email]> wrote:
>
> How does/would 4D handle a set
> name which was constructed in this manner but was/became an IP set?
> Would 4D flag the method as thread unsafe?

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
constructing an IP set name (as in my example) could be done on the
server, or for single user applications.

This is (only some what) of a hypothetical, or thought experiment.
Chip

On Wed, 11 Jul 2018 15:35:35 -0400, Jeffrey Kain via 4D_Tech wrote:

> Are you doing all this in single user mode?
>
> I think a lot of people don't realize that preemptive threads aren't
> supported on 4D Remote at all.
>
>> On Jul 11, 2018, at 3:31 PM, Chip Scheide via 4D_Tech
>> <[hidden email]> wrote:
>>
>> How does/would 4D handle a set
>> name which was constructed in this manner but was/became an IP set?
>> Would 4D flag the method as thread unsafe?
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************
---------------
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Hopefully, 4D remote could be supported in 4D 18:-(

However, 4D server (thus triggers) is supported. I'm just wondering does anyone try that out on triggers?

Alan Chan

4D iNug Technical <[hidden email]> writes:
>Are you doing all this in single user mode?
>
>I think a lot of people don't realize that preemptive threads aren't supported on 4D Remote at all.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
there is no "thread safe" property for triggers.

however,

if you use commands like SAVE RECORD, DELETE RECORD
from a method chain that is marked as thread safe,
then the call chain of that table's trigger is checked for thread safety at compile time.

in fact the compiler is smart enough to resolve expressions such as Table(n)->
(all triggers are inspected for such expressions, so actually its better to use absolute tokens)

2018/07/12 12:20、Alan Chan via 4D_Tech <[hidden email]<mailto:[hidden email]>> のメール:
 I'm just wondering does anyone try that out on triggers?


**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
Of course, SAVE RECORD, DELETE RECORD is needed to invoke trigger. However, the method that call SAVE RECORD would be executed in 4D Remote and 4D Remote isn't supported. A dead lock?

Alan Chan

4D iNug Technical <[hidden email]> writes:

>there is no "thread safe" property for triggers.
>
>however,
>
>if you use commands like SAVE RECORD, DELETE RECORD
>from a method chain that is marked as thread safe,
>then the call chain of that table's trigger is checked for thread safety at compile time.
>
>in fact the compiler is smart enough to resolve expressions such as Table(n)->
>(all triggers are inspected for such expressions, so actually its better to use absolute tokens)
>
>2018/07/12 12:20、Alan Chan via 4D_Tech <[hidden email]<mailto:[hidden email]>> のメール:
> I'm just wondering does anyone try that out on triggers?
>
>

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
I agree it would be nice to eventually have preemptive mode on the client side, but I also think the subject needs to be discussed in context.

Preemptive mode makes it possible to run multiple processes independent of each other concurrently, so the primary benefactor should be the server.

After all, preemptive processes can't have a UI, neither can it sync with other processes (without using semaphores etc.), so in many ways its like a stored procedure (and not a method with the “execute on server” property.)

2018/07/12 13:36、Alan Chan via 4D_Tech <[hidden email]<mailto:[hidden email]>>のメール:
Of course, SAVE RECORD, DELETE RECORD is needed to invoke trigger. However, the method that call SAVE RECORD would be executed in 4D Remote and 4D Remote isn't supported. A dead lock?



**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
Should have clarified: the reason why I bring up the “execute on server” property is because a trigger is kind of like a specific version of such methods.

2018/07/12 14:41、Keisuke Miyako via 4D_Tech <[hidden email]<mailto:[hidden email]>>のメール:
After all, preemptive processes can't have a UI, neither can it sync with other processes (without using semaphores etc.), so in many ways its like a stored procedure (and not a method with the “execute on server” property.)



**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Simply put, preemptive triggers are not for client/server operations even all the codes are preemptive-compliant.

- data entry UI and do entry data
- click a button call a method that contains SAVE RECORD that invoke trigger in server and all codes in this method itself and codes in trigger are all preemptive-compliant
- In this case, trigger won't be preemptive because the method above was called from UI.

Am I correct?

TIA

Alan Chan

4D iNug Technical <[hidden email]> writes:

>I agree it would be nice to eventually have preemptive mode on the client side, but I also think the subject needs to be discussed in context.
>
>Preemptive mode makes it possible to run multiple processes independent of each other concurrently, so the primary benefactor should be the server.
>
>After all, preemptive processes can't have a UI, neither can it sync with other processes (without using semaphores etc.), so in many ways its like a stored procedure (and not a method with the “execute on server” property.)
>
>2018/07/12 13:36、Alan Chan via 4D_Tech <[hidden email]<mailto:[hidden email]>>のメール:
>Of course, SAVE RECORD, DELETE RECORD is needed to invoke trigger. However, the method that call SAVE RECORD would be executed in 4D Remote and 4D Remote isn't supported. A dead lock?
>
>
>
>**********************************************************************
>4D Internet Users Group (4D iNUG)
>FAQ:  http://lists.4d.com/faqnug.html
>Archive:  http://lists.4d.com/archives.html
>Options: https://lists.4d.com/mailman/options/4d_tech
>Unsub:  mailto:[hidden email]
>**********************************************************************

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
On Thu, Jul 12, 2018 at 8:11 AM Alan Chan via 4D_Tech <[hidden email]>
wrote:

> Simply put, preemptive triggers are not for client/server operations even
> all the codes are preemptive-compliant.
>
> - data entry UI and do entry data
> - click a button call a method that contains SAVE RECORD that invoke
> trigger in server and all codes in this method itself and codes in trigger
> are all preemptive-compliant
> - In this case, trigger won't be preemptive because the method above was
> called from UI.
>
> Am I correct?
>
>
I believe not.

UI cannot run in preemptive process, that is requirement of underlying OS
that require that all UI runs in the main thread. But there is no reason
why the trigger, running on server, could not run in a separate preemptive
thread.

I believe much of the confusion is caused by mixing up 4D-level processes
with OS-level threads. OS thread is preemptive or not and cannot switch
between two. 4D process runs in one OS thread and thus cannot switch
between preemptive and cooperative, but that does not hold for server
triggers. Even when invoked from non-preemptive 4D process, trigger runs on
its own OS-level thread on server machine and that thread can be preemptive.

--

Peter Bozek
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
Thanks. OK. Forget about the syntax, just the idea.

- open data entry dialog
- check button value
- if button value is validate, save all new value in an object, then call worker with object and form window process as parameters
- the worker process create new/load an existing record and modify based on value in object and do SAVE RECORD in transaction
- worker process call form to notify the entry dialog if transaction if OK or rejected

Would it be OK?

Alan Chan


4D iNug Technical <[hidden email]> writes:

>UI cannot run in preemptive process, that is requirement of underlying OS
>that require that all UI runs in the main thread. But there is no reason
>why the trigger, running on server, could not run in a separate preemptive
>thread.
>
>I believe much of the confusion is caused by mixing up 4D-level processes
>with OS-level threads. OS thread is preemptive or not and cannot switch
>between two. 4D process runs in one OS thread and thus cannot switch
>between preemptive and cooperative, but that does not hold for server
>triggers. Even when invoked from non-preemptive 4D process, trigger runs on
>its own OS-level thread on server machine and that thread can be preemptive.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
transactional data entry is kind of task you would typically want to avoid using preemptive mode.

DB4D requests (19814) are all preemptive since v11,
so if you call the command SAVE RECORD on the client side (a cooperative process),
the request is still processed on the server side in preemptive mode (i.e. you don't congest the server).

it sort of becomes a moot point that you are calling the command in cooperative mode,
because the bulk of the work (marshalling data and exchanging it via the network) is done in preemptive mode any way. same for Begin SQL/End SQL, which is not thread safe, but of course SQL requests (19812) are all preemptive since v11.

2018/07/12 16:55、Alan Chan via 4D_Tech <[hidden email]<mailto:[hidden email]>> のメール:

Thanks. OK. Forget about the syntax, just the idea.

- open data entry dialog
- check button value
- if button value is validate, save all new value in an object, then call worker with object and form window process as parameters
- the worker process create new/load an existing record and modify based on value in object and do SAVE RECORD in transaction
- worker process call form to notify the entry dialog if transaction if OK or rejected

Would it be OK?

Alan Chan



**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
I'm a bit confused.

When I just call SAVE RECORD in data entry form (cooperative process), I was told it's not OK because it's from a process that have UI. Now, your latest reply claimed it's OK. Or only if there's no trigger and transaction?

If I create a new process that contain "no" UI from application process, this is again, not OK.

When 4D announced preemptive thread is supported in triggers as long as no IP variables, I thought this is game changer that 4D could move to enterprise solution. Obviously, it's just my illusion. It seems all these game changer features in 16 and
17 are only beneficial for 4D based web server but not traditional client/server solution developers.

Alan Chan

4D iNug Technical <[hidden email]> writes:
>DB4D requests (19814) are all preemptive since v11,
>so if you call the command SAVE RECORD on the client side (a cooperative process),
>the request is still processed on the server side in preemptive mode (i.e. you don't congest the server).
>
>it sort of becomes a moot point that you are calling the command in cooperative mode,
>because the bulk of the work (marshalling data and exchanging it via the network) is done in preemptive mode any way. same for Begin SQL/End SQL, which is not thread safe, but of course SQL requests (19812) are all preemptive since v11.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
On Thu, Jul 12, 2018 at 11:47 AM Alan Chan via 4D_Tech <[hidden email]>
wrote:

> I'm a bit confused.
>
> When I just call SAVE RECORD in data entry form (cooperative process), I
> was told it's not OK because it's from a process that have UI. Now, your
> latest reply claimed it's OK. Or only if there's no trigger and transaction?
>
> Alan,

As I understand it, if you have a C/S, SAVE RECORD runs in its own
preemptive thread _on server_. It does not matter if 4D process that called
SAVE RECORD is preemptive or not. As clients does not run preemptive
processes, the whole point seems to be moot.

On single user, SAVE RECORD and the trigger(s) it executes runs in the same
system thread the process that called SAVE RECORD. It means that if you
want to save record in preemptive process, both the method that executes SAVE
RECORD and the trigger need to be able to run preemptively. In fact, as I
understand it, all triggers need to be able to run preemptively.

It means that to do what you described - pass record to worker to be saved
in preemptive thread - would make difference in single user only. But there
you would not gain anything from calling SAVE RECORD in a worker.
Additional messaging with another thread will rather slow the application
down.


> If I create a new process that contain "no" UI from application process,
> this is again, not OK.
>
> When 4D announced preemptive thread is supported in triggers as long as no
> IP variables, I thought this is game changer that 4D could move to
> enterprise solution. Obviously, it's just my illusion. It seems all these
> game changer features in 16 and
> 17 are only beneficial for 4D based web server but not traditional
> client/server solution developers.
>

That is not my understanding.

--

Peter Bozek
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
That's what I understand in the first place as following.

- do data entry in a form (UI in application process)
- in the form, I click a button call SAVE RECORD (in the same applicaation process)
- As long as all codes in the trigger are preemptive compliant, the trigger would be running in preemptive mode in server.

However, Miyako San said it won't work on first reply due to UI but seems OK on 2nd reply (because of my unclear description). Just want to confirm before I rewrite all trigger codes (not trivial) and move away all IP variables.

Alan Chan

4D iNug Technical <[hidden email]> writes:

>As I understand it, if you have a C/S, SAVE RECORD runs in its own
>preemptive thread _on server_. It does not matter if 4D process that called
>SAVE RECORD is preemptive or not. As clients does not run preemptive
>processes, the whole point seems to be moot.
>
>On single user, SAVE RECORD and the trigger(s) it executes runs in the same
>system thread the process that called SAVE RECORD. It means that if you
>want to save record in preemptive process, both the method that executes SAVE
>RECORD and the trigger need to be able to run preemptively. In fact, as I
>understand it, all triggers need to be able to run preemptively.
>
>It means that to do what you described - pass record to worker to be saved
>in preemptive thread - would make difference in single user only. But there
>you would not gain anything from calling SAVE RECORD in a worker.
>Additional messaging with another thread will rather slow the application
>down.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
In reply to this post by 4D Tech mailing list
I'm about to try it in a stored procedure to convert journal files (created every 30 seconds for the mirror) into json.

> On Jul 11, 2018, at 11:20 PM, Alan Chan via 4D_Tech <[hidden email]> wrote:
>
> However, 4D server (thus triggers) is supported. I'm just wondering does anyone try that out on triggers?

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Does it make sense for most triggers? Usually you want to know for sure that code in a trigger has completed before doing anything else in the table/process, which is kind of the opposite of a preemptive thread.

I suppose for some triggers it would be suitable.

> On Jul 11, 2018, at 11:52 PM, Keisuke Miyako via 4D_Tech <[hidden email]> wrote:
>
> I'm just wondering does anyone try that out on triggers?

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
On Thu, Jul 12, 2018 at 1:57 PM Jeffrey Kain via 4D_Tech <
[hidden email]> wrote:

> Does it make sense for most triggers? Usually you want to know for sure
> that code in a trigger has completed before doing anything else in the
> table/process, which is kind of the opposite of a preemptive thread.
>
>
Jeff,

I believe it should provide some speed improvement (to make triggers
preemptive.) IF they are not, triggers are executed sequentially at server,
one trigger executed after another. If they are preemptive, each trigger
can get their own preemptive thread, with several triggers executed (on
server) in parallel. However, disk speed as main bottleneck will not be
affected by this, so you can see significant or zero improvement.

That does not mess with order execution, triggers are started after client
calls SAVE RECORD and only after trigger finishes - does not matter if in
preemptive or cooperative thread - execution on client moves to next line.


> I suppose for some triggers it would be suitable.
>
>
As I understand, you have to make all triggers preemptive to work.

--

Peter Bozek
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
Is it just me, or does anyone else expect that a database engine would handle preemptive threads, transactions and concurrence transparently?

Why would I need to know about cooperative versus preemptive threads in the best of worlds?

Paul

> On 12 Jul 2018, at 15:19, Peter Bozek via 4D_Tech <[hidden email]> wrote:
>
> On Thu, Jul 12, 2018 at 1:57 PM Jeffrey Kain via naine w4D_Tech <
> [hidden email]> wrote:
>
>> Does it make sense for most triggers? Usually you want to know for sure
>> that code in a trigger has completed before doing anything else in the
>> table/process, which is kind of the opposite of a preemptive thread.
>>
>>
> Jeff,
>
> I believe it should provide some speed improvement (to make triggers
> preemptive.) IF they are not, triggers are executed sequentially at server,
> one trigger executed after another. If they are preemptive, each trigger
> can get their own preemptive thread, with several triggers executed (on
> server) in parallel. However, disk speed as main bottleneck will not be
> affected by this, so you can see significant or zero improvement.
>
> That does not mess with order execution, triggers are started after client
> calls SAVE RECORD and only after trigger finishes - does not matter if in
> preemptive or cooperative thread - execution on client moves to next line.
>
>
>> I suppose for some triggers it would be suitable.
>>
>>
> As I understand, you have to make all triggers preemptive to work.
>
> --
>
> Peter Bozek
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:[hidden email]
> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: just a curiosity - pre emptive threads

4D Tech mailing list
In reply to this post by 4D Tech mailing list
I don't need preemptive client side on data updates. I care about server side only. Data entry/updates are human works in our case, one at a time (one entry per second through barcode scanner). If triggers on server could be completed in less time
even when server loading is heavy, it won't drag down data entry on client side. Say 200 users are doing data entries through barcode in multiple shops, 200 triggers in every second and each trigger update multiple tables. Customers are queueing
long lines on POS counters, it's not fun. Hong Kong is a crazy city, shops are packed of people even in LV shops. In some cases, shops do crowd control:-(

For me, preemptive 4D Remote (if it's available) might be helpful on progress bar update in tight loop operations. Redrawing progress bar in cooperative process take up way more time than actual loop.

Alan Chan

4D iNug Technical <[hidden email]> writes:
>Does it make sense for most triggers? Usually you want to know for sure that code in a trigger has completed before doing anything else in the table/process, which is kind of the opposite of a preemptive thread.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[hidden email]
**********************************************************************
12