Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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.

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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,

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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.

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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

Re: just a curiosity - pre emptive threads

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?

Re: just a curiosity - pre emptive threads

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

just a curiosity - pre emptive threads

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