Hey, David Porter spotted a bug in my code and I wanted to push this part of the thread up to the list for the archives, etc.:
On Tue, Sep 26, 2017 at 5:05 PM, David Porter <[email protected]> wrote: > Thanks for posting the LogWorker code, it has been fun experimenting with it. > > I have been testing only the preemptive test code. > Running on a Mac Pro (Late 2013) with 6-Core Intel Xeon E5 , Mac OS X 10.12.6 > 4D 16.1 hotfix 2 , 64 bit app. ( Not server ) > > Yes, there is a bug in the code. > Method: LogWorker_Kill ,need to add the line > Log_Path:=“” // This is required to get the LogWorker_Start code to open the log again > > Even so, your code would crash interpreted before the Kill was ever sent. > Putting in delay process in LogWorker_CallABunch_Preemptive, would get it to run interpreted. > So, clearly there is a 4D bug here. > > Compiled, I am able to remove all the delay processes, and run it to completion. > I do get some runtime errors about broken communication. > Again, I can make them go away with some delay processes, something I was trying to avoid. > > So, I encourage you to take another look at this code. > My first reply, before checking the code based on what David said: Hey! Thanks for checking the code, you're awesome! Thanks for the bug catch on my code. I'm sure that wasn't from me. Darn kids, getting into my code and messing things up.... How long did you have to delay process compiled to get it to work? I tried up to 3 seconds and it still didn't work. In theory (as I understand it), DELAY PROCESS should *not* be needed. Meanin, CLOSE DOCUMENT should not return until the document is actually closed. I think I even tried it with SET CHANNEL and found the same problem, but don't quote me on that. If my understanding about the synchronous nature of the file/channel commands is correct, and a process delay is needed, it points to an underlying problem that would leave me not trusting the solution. Even if it only shows up after a few hours/days/weeks...that's not good enough :( My second reply now: Okay, I've gone back and updated the code, just as David described. That fix makes the system *way* better. Unfortunately, even with that fix and the 3 second delay, the problem still crops up. It takes longer, but it's still there. I guess it's an (un)happy coincidence that my bug amplified an underlying bug in 4D. For a logging situation, a race condition rate of 1:1,000,000 isn't even close to good enough. It needs to be zero. Always. In this case, i was able to provoke the bug in a few minutes :( I'm told that 4D has accepted my report but Partners in Aus don't have direct access to the bug system. And I've never heard anything from France so I don't have a bug report number or anything else to do on. ********************************************************************** 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] **********************************************************************
