first up, I myself am still in the process of learning how workers work, and I totally agree one should probably start with small POCs or relatively minor tasks before going full on.
what I think I leaned so far: keep in mind a CALL WORKER can create a new worker if the previous one was killed. for instance. imagine a recursive worker method, using process variables for context, aborted for whatever reason from the debugger or runtime explorer. the worker is killed, but a new "call" comes in from the previous context, starting a new worker that has no idea where the previous worker left off. that can be a nightmare. keep in mind a client process can never be preemptive. most (if not all) published examples are designed for single user, where some background processes are spawned simultaneously and report to a UI process. they explain how workers work, but in client server all the spawned workers will be cooperative, sharing the same core as the UI process, not really a show care for preemptive multi-processing. 2017/05/07 12:59、David Adams via 4D_Tech <[email protected]<mailto:[email protected]>> のメール： So, yeah, CALL WORKER is 100% appropriate, a preemptive worker is 100% appropriate...and the ability to break the who ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
