Andreas, can you tell me what code you used that generated an error? I'd
like to reproduce that.


Okay, super weird findings. I'm not sure what the behavior is meant to be.
Yesterday, I spent 5-10 minutes setting up a new scratch database to test
this stuff out a bit. I created a preemptive worker method with no code -
just something to serve as a launching point. I then tried passing in
various bits of code via CALL WORKER to see what would happen. What I was
hoping for was a trappable error. Since these errors are only going to
happen in compiled mode at runtime, I want to be able to detect them. This
way, you can set up a set of tests to process the kinds of code you plan to
run this way before shipping a product with runtime-only bugs.

So. I tend to keep my sketches simple. I figured "try something illegal". I
tried ALERT. As it turns out, it's not illegal, it shows up in User. (Well,
it shows up in some situations but not others, for some reason.) That's
documented, I just didn't know. So then I tried Open window and a loop with
MESSAGE. Not allowed. But it didn't generate an error. No window, no
messages, no error.

After Andreas wrote back, I figured I'd look a little more, and a little
more carefully. Anyway, I moved on to other illegal commands. I tried
DIALOG and Begin/End SQL blocks. No errors. But I did notice something
interesting by using the Runtime Explorer's process list. You can see from
the icon what sort of process a worker is. I launch the preemptive worker,
all good. I pass in illegal code and the worker tends to become cooperative
and/or be killed. So, it switches mode on the fly, doesn't necessarily run
the provided code, and at no point throws an error.

Assuming that I'm not doing something silly and confusing myself, the
behavior I'm seeing is problematic in a few ways:

1) I'm passing code into a worker and it's not being executed. That could
be a show-stopper.

2) I'm passing in illegal code, 4D's recognizing the problem and dealing
with it by (it seems) suppressing the code...but I'm not getting an error.
How am I meant to know that I've done something wrong?

3) 4D seems to be killing and respawning the worker. Also a potential
show-stopper. Why? A nice feature of workers is that they *persist*. That
gives you a group of variables/selections/etc. that is stable and
(semi-)protected for the lifespan of the worker. If you kill the worker,
you lose all of that state/data. Well, passing in a bad call seems to be
enough to wipe all of that data out without notice and restart the worker
on the main core.

Given how much unexpected behavior I've found in just a few minutes of
looking, I'm guessing that I've got an incomplete and inaccurate picture in
my head of how all of this works. I'd be very grateful to anyone else that
will set up some tests and see what they see. It really only takes a couple
of minutes. It's super easy to get tunnel vision when you start tracking
stuff of this sort down so there's nothing better than a few people
pursuing the question in their own way.

For the record, this is a brand new, V16 database built from scratch.
There's nothing much in it, just bare bones stuff to take a look at this
behavior. I've not set a custom error handler so I should see 4D's default
error dialogs. I'm not sure what to make of it all.

Note: I've checked the docs and did not find any discussion of what is
supposed to happen when you pass 'illegal' code to a preemptive thread:

Preemptive 4D processes
http://doc.4d.com/4Dv16/4D/16/Preemptive-4D-processes.300-3036340.en.html

CALL WORKER
http://doc.4d.com/4Dv16/4D/16/CALL-WORKER.301-3036044.en.html
**********************************************************************
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
**********************************************************************

Reply via email to