Hey John, we ended up testing different things, I didn't ever get too far into the memory side. (Thanks for that, good to know.) I retested again last night and I can kill 4D from entirely legal code. I'll show you at dinner, if you like. There is a *concurrency bug*.
I'm not convinced that everyone at 4D fully grasps the nature of a concurrency bug and they're definitely not grasping their importance. It's an existential bug. What's going on should be *impossible*. I don't mean rare (it is rare, but not that rare.) There's a _reason_ I've reported this bug and have been going on about it. When do I normally do that? I don't. And it is extremely unlikely that I ever will again. There's a margin in doing so, but it's pretty much all negative margin ;-) They should email Laurent E., he understands concurrency perfectly and should appreciate the situation. Plus, I think this feature set comes from him. It's possible Engineering will discover that it's a highly specific and localized bug, not a more generalized bug - let's hope so. But there is *no* way for us to know that on the outside. I could keep probing to get a better sense of the shape of the bug, but that's a massive misuse of my time. I've got real work to do. So, no logging to files via a worker in 4D for me :( I think that I can still use normal processes to do a record-based passthrough, but that's a very different performance proposition entirely. (There's no way that I can use that approach for the Web logs, I've killed 4D before that way...not doing it again.) ********************************************************************** 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 **********************************************************************
