On Nov 1, 2016, at 4:49 PM, David Adams wrote: > There's a note about docrefs being shared in cooperative threads and not > shared in preemptive threads. I'm not at all clear what that means. I would > expect you would pass paths anyway...isn't that what everyone does now > anyway?
I think this means you do something like: <>docRef_h:=Open document(“logfile.txt”) in one process. Then in another process you can do: SEND PACKET(<>docRef_h;”a message for the log file”) So you open the log file once in your On Startup method. Then from every process that is running you can just do a SEND PACKET to the already open file. Of course the change is easy. Just use APPEND TO DOCUMENT command and, as you said, pass a file path instead of a DocRef to the worker. I can see how each preemptive worker would not have access to open files in other processes, cooperative or preemptive. The preemptive thread is almost like a separate application and if it tried to write to that <>docRef_h it would fail because it would not have context. The data structure behind <>docRef_h for a file on disk is unknown. The worker process is living in its own world and has no access to 4D things that are shared among processes. Other examples of a shared things that any process — and even components — can access are hierarchical list references and menu references. (I actually didn’t know that document references were shared among processes. I’ve never utilized that “feature”.) > Anyway, that's all pretty deep in the weeds so I'll go back to my original > question: What problems are people having that server-side, preemptive > threads going to solve? I'll be very curious to hear about examples. And > I'll also immediately wonder if those problems can't be solved with a > different architecture using any version of 4D. Maybe not a better > solution, but good to have in the mix. (Multiple machine redundant > processing to good results has been around as long as 4D Server itself.) If > you are served better by a different architecture, it makes a big > difference in how you approach interprocess/inter-machine messaging, so > it's worth thinking through. I have a client that I know for sure will upgrade to v16 early next year. The very first thing I will do when I upgrade to v16 is make sure that all the triggers are running preemptive. That’s step #1. Get those triggers to run as fast as possible on the server. Everyone should benefit from that. Step #2 will be to try and redesign some of the queries and reports that now take many seconds to run. I’ll break the queries and report calculations into pieces and do each piece in a worker and then at the end combine the results. Now it all runs in 1 core. Maybe breaking it into 4 parts and running it in 4 cores simultaneously will result in faster execution time. So the idea is the “CalculateTotals” method at the beginning of the report method that builds a bunch of arrays of totals will be rewritten to be preemptive. The rest of the report method will not need to be changed. “CalculateTotals” is where all the work will be done. I’ll set it to “execute on server”. Then split things into 4 pieces, call 4 workers, wait for them all the finish and then combine everything into a single set of arrays. Tim ******************************************** Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ******************************************** ********************************************************************** 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 **********************************************************************
