Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

Oops... I reply too fast. You've answered your question.

Alan Chan

Chip Scheide <4d_o...@pghrepository.org> writes:
>(I think that to get around the Set process variable you would use 
>'Storage')

**
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

May be using Shared Object to replace variable.

Alan Chan

4D iNug Technical <4d_tech@lists.4d.com> writes:
>1 - doesn't this idea 'break' with preemptive code (using Set Process 
>Variable)?
>(I think that to get around the Set process variable you would use 
>'Storage')
>2 - how does 4D know/stop/manage code lie the following from doing 
>executing Set Process Variable into a preemptive process?

**
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Chip Scheide via 4D_Tech]

to beat a dead horse(?)...
in either stand alone, or C/S (on the server)

I have deamons running (process which execute in a repeat until(exit 
4D) loop)
There is no reason (see below) based on the code in the deamons, that 
these deamons can not be set to run in preemptive mode.
 
One of the ways to ensure a "clean" exit of these processes/code, 
pointed out by Tim was to use
Set Process Variable to set a boolean process variable in the deamon 

>Tech Tip: Always make sure your Stored Procedure is able to gracefully quit 
http://kb.4d.com/assetid=77839

This leads to 2 questions
1 - doesn't this idea 'break' with preemptive code (using Set Process 
Variable)?
(I think that to get around the Set process variable you would use 
'Storage')
2 - how does 4D know/stop/manage code lie the following from doing 
executing Set Process Variable into a preemptive process?

$Execute:="SET PROCESS VARIABLE("+String($Process_ID)+\
Semi_Colon_Char+$Variable+Semi_Colon_Char+$Value+")"
EXECUTE FORMULA($Execute)

Where $Process_ID is a preemptive process

Thanks
Chip


On Thu, 12 Jul 2018 23:12:59 +0800, Alan Chan via 4D_Tech wrote:
> Why not? It isn't supported? I just checked In Transaction in trigger 
> is a preemptive compliant. It means, preemptive mode does expect 
> transaction. Any hidden constraint?
> 
> Without transaction, trigger is meaningless. When a trigger invoked, 
> mulitple tables might be updated inside the trigger. When trigger was 
> rejected, other updated tables won't roll back except the trigger 
> invoking table. This would cause serious
> data integrity issue.
> 
> Alan Chan
> 
> 4D iNug Technical <4d_tech@lists.4d.com> writes:
>> transactional data entry is kind of task you would typically want to 
>> avoid using preemptive mode.
> 
> **
> 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:4d_tech-unsubscr...@lists.4d.com
> **
---
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

Why not? It isn't supported? I just checked In Transaction in trigger is a 
preemptive compliant. It means, preemptive mode does expect transaction. Any 
hidden constraint?

Without transaction, trigger is meaningless. When a trigger invoked, mulitple 
tables might be updated inside the trigger. When trigger was rejected, other 
updated tables won't roll back except the trigger invoking table. This would 
cause serious
data integrity issue.

Alan Chan

4D iNug Technical <4d_tech@lists.4d.com> writes:
>transactional data entry is kind of task you would typically want to avoid 
>using preemptive mode.

**
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Jeffrey Kain via 4D_Tech]

Well, the engine does handle preemptive threads completely transparently since 
version 11. We're talking about code that you write for your custom application.



> On Jul 12, 2018, at 10:02 AM, Paul Lovejoy via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Is it just me, or does anyone else expect that a database engine would handle 
> preemptive threads, transactions and concurrence transparently?

**
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

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 <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Paul Lovejoy via 4D_Tech]

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 <4d_tech@lists.4d.com> 
> wrote:
> 
> On Thu, Jul 12, 2018 at 1:57 PM Jeffrey Kain via naine w4D_Tech <
> 4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
> **
**
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Peter Bozek via 4D_Tech]

On Thu, Jul 12, 2018 at 1:57 PM Jeffrey Kain via 4D_Tech <
4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Jeffrey Kain via 4D_Tech]

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 
> <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Jeffrey Kain via 4D_Tech]

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 <4d_tech@lists.4d.com> 
> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

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 <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Peter Bozek via 4D_Tech]

On Thu, Jul 12, 2018 at 11:47 AM Alan Chan via 4D_Tech <4d_tech@lists.4d.com>
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

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 <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Keisuke Miyako via 4D_Tech]

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 
<4d_tech@lists.4d.com> のメール：

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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

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 <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Peter Bozek via 4D_Tech]

On Thu, Jul 12, 2018 at 8:11 AM Alan Chan via 4D_Tech <4d_tech@lists.4d.com>
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

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 <4d_tech@lists.4d.com> 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 
><4d_tech@lists.4d.com>のメール:
>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:4d_tech-unsubscr...@lists.4d.com
>**

**
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Keisuke Miyako via 4D_Tech]

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 
<4d_tech@lists.4d.com>のメール:
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Keisuke Miyako via 4D_Tech]

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 
<4d_tech@lists.4d.com>のメール:
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

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 <4d_tech@lists.4d.com> 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 
><4d_tech@lists.4d.com> のメール：
> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Keisuke Miyako via 4D_Tech]

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 
<4d_tech@lists.4d.com> のメール：
 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Alan Chan via 4D_Tech]

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 <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Chip Scheide via 4D_Tech]

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 
>> <4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com
> **
---
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:4d_tech-unsubscr...@lists.4d.com
**

Re: just a curiosity - pre emptive threads

[Jeffrey Kain via 4D_Tech]

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 <4d_tech@lists.4d.com> 
> 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:4d_tech-unsubscr...@lists.4d.com
**

just a curiosity - pre emptive threads

[Chip Scheide via 4D_Tech]

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:4d_tech-unsubscr...@lists.4d.com
**