the reason why I think
> CALL WORKER("Preemptive_Worker";"MethodWithCooperativeCode")
or more specifically
> CALL WORKER("Preemptive_Worker";"MethodWithPreemptiveCode")
> CALL WORKER("Preemptive_Worker";"MethodWithCooperativeCode")
is not a problem goes like this:
4D performs 2 checks; checking at compilation time, and checking at runtime.
the first check is well documented. every method with the "run preemptive"
property is validated,
that no thread-unsafe commands or methods or inter-process variables or plugins
or Begin SQL~End SQL blocks are called.
if the "use preemptive web processes" database property is activated,
web-related database methods, compiler_web, triggers and methods that are
public on 4D Mobile are also validated.
then there is the second, runtime (or platform) check.
unicode mode must be active, the app must be 64-bit, compiled, the type must be
either server or desktop.
if none of these conditions are met, all processes are automatically
cooperative, no error.
and this is where we feel like we are entering uncharted territory; the list of
"what if" s.
I try to categorise the potential issues this way:
1. references
any "references", that are "safe" in that they are not interprocess variables
(therefore pass the first test),
only work within the same preemptive process that created it, or across
cooperative processes.
these include DocRef, DOM ref, and yes, pointers.
http://doc.4d.com/4Dv16R2/4D/16-R2.1620/Preemptive-4D-processes.300-3111846.en.html
the code pass the first test, but breaks in that the references are invalid.
the error itself does not suggest thread-safety per-se,
they are just classic runtime errors due to invalid references.
there is a special provision for objects; an implicit OB Copy is called by CALL
WORKER.
http://doc.4d.com/4Dv16R2/4D/16-R2.1620/CALL-WORKER.301-3111543.en.html
2. execution
using interprocess variables inside PROCESS 4D TAGS,
EXECUTE FORMULA, EXECUTE METHOD, etc.
the process has already been started as preemptive,
but an attempt to run cooperative code in the same context has been made.
the error specifically mentions that thread-safety is the problem.
3. calling
I think this is the type of issue we are discussing right now.
CALL WORKER is used to "run cooperative code in an existing preemptive process"
it is similar to issue #2 but different in the sense that it is not the current
context that is asked to break thread safety.
when asked to "call worker", 4D already knows that the method is thread unsafe,
and so is the target process (worker).
the instruction is simply impossible to execute.
so what happens? nothing (that has been my experience).
incidentally, what I find interesting about CALL WORKER is that a worker
remembers the name of the method that started it off,
and you can invoke that method by passing an empty string.
http://doc.4d.com/4Dv16R2/4D/16-R2.1620/CALL-WORKER.301-3111543.en.html
if we followed that rule and always passed an empty string, we would never have
this problem. just saying...
now your feature request, if I understand correctly, talks about detecting, on
the receiving end,
if a request to execute cooperative code has been received in a preemptive
process.
I think it is not a problem, since there is nothing to receive since CALL
WORKER does make such requests.
http://forums.4d.fr/Post//19391591/1/
> What happens when you send an illegal instruction to a worker that's running
> in preemptive mode?
> I've done my own quick tests and asked around, and here's what I've found:
>
> * I don't get an error.
> * The worker may be restarted in cooperative mode. Which may end up clearing
> existing variables and so on (?)
> * Other people report getting an error.
> * Sometimes I get an error.
> * Sometimes an error handler catches, sometimes it doesn't.
>
> It's wildly unpredictable.
I agree the documentation could be better, by giving more specific examples of
each scenario.
but by and large, I think the results are pretty predictable for each case.
> * I don't get an error.
this must be CALL WORKER asked to do something impossible. (issue #3 above)
> * The worker may be restarted in cooperative mode. Which may end up clearing
> existing variables and so on (?)
the worker must have been killed or aborted.
> * Other people report getting an error.
some "eval" code must have been executed in the worker (issue #2 above)
> * Sometimes I get an error.
> * Sometimes an error handler catches, sometimes it doesn't.
a mix of all the other problems, just presenting themselves in random order?
**********************************************************************
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:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
