I also have a question about this ... In our database we require at least one user window to always be open. When a user closes a window, the close method counts the number of user windows and if there is only one, it doesn't allow it to be closed. However ... If the user has opened another window within the same process (for a preview, for example), 4D now thinks there are two user windows open, and it allows the user to close it ... which of course closes both of the windows. Other than keeping track of all open windows-within-windows, which is messy, is there any way to differentiate main windows and their associated windows within the same process?
PB On Wed, 26 Jun 2019 at 16:08, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> wrote: > Hi Chris, > Good questions. Here are my thoughts on them based on what I've picked up > from the World Tour and Summits. > > On Wed, Jun 26, 2019 at 12:31 AM Chris Belanger via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > > > 1) What is the reasonable limit as to how many windows/dialogs should get > > opened in the same process? > > > This is going to be limited by the resources available to 4D. A laptop with > the minimum RAM and processor is going to have a lower limit than a nice > new Mac Pro by a long way. > > But there's no reason to be opening a huge number of windows. A window is > really a UI portal as it were. We no longer need to hack certain operations > with 'offscreen' or 'hidden' windows so a good design should open a window > for something useful. > > On top of that now it's really easy and fast to completely repurpose what a > window is 'doing' anyway. You could design a window interface to be a lot > like the OS window interfaces are - you display something and then > completely change it based on a user action. But now we could revert to any > previous window content like the back button on a Finder window. You would > have to retain the displayed form and the Form contents but with that info > you could reload a past window. > > So I think this is a case where the technical limit on the number of > windows is less important than building a good design for the interface. > > > > 2) do windows that share the same process also share processing time? > What > > I mean is: If window A is executing, does window B have to wait until > > Window A is done before any processing it does would start (think CALL > FORM > > ( window ) )? > > > > For example: Window A is doing a QUERY that takes a few seconds. Does > that > > make Window B (in the same process) unresponsive until Window A has > > finished the QUERY? > > > Prior to preemptive processes each instance of 4D ran on a single core of > the machine. How the CPU cycles were allocated and prioritized was between > 4D and OS. To us it looked like multiple processes were running 'parallel' > but it was all happening on a single core. The only way you could truly > have parallel processing was by using server side processes or EXECUTE ON > CLIENT and each of those instances were limited in the same way. > > With a preemptive process you can truly have different processes running > concurrently on different cores. Thomas Maul has some great demos of this. > If you aren't a Partner (they may be walled off from non-partners) check > out a presentation he did for 4DMethod <https://4dmethod.com/>. He also > includes a demo of why pre-emptive processing only matters on actual > hardware, not virtualized machines. I forget if that's in the 4DMethod > preso or I saw it at a Summit. Bottom line: preemptive is meaningless on a > virtual machine because the virtual machine is running virtual cores and > then entire virtual machine is running on a single instance of the host > machine. So, if you plan to deploy on AWS or the like don't worry about > preemptive, just use CALL WORKER. > > So all the windows in the UI process will work, essentially, like the > windows in the separate processes we used to use. 4D has optimized things > like query a lot, for example. And the speed is improved significantly. I > hear in v18 ORDA may be as fast as classic 4D queries. > > > > 3) I used separate processes before because it was possible to do > > ‘parallel processing’ that way. Because windows were in separate > processes, > > anything one window was working on would not impact the responsiveness of > > other windows. > > Is it still advisable to break out windows under its own process if it > may > > need to do substantial processing at times? > > > It would be better to break out the heavy operations using CALL WORKER. > This is really what it's designed for. > > Underlying all this is the question of memory management. I have the > impression 4D is committed to optimizing memory use. New process > <https://doc.4d.com/4Dv17R5/4D/17-R5/New-process.301-4128085.en.html> > recommends 0 for the stack size, "Pass 0 in stack to use a default stack > size, suitable for most applications (recommended setting)." The docs go on > to say the size is not total process memory and is influenced by things > like number of windows, number of forms, and so on. This isn't anything new > and doesn't address the situation you start off asking about. > > I expect the memory allocation when you pass 0 stack size has been > addressed but it would be good for someone closer to the engineering team > to weight in on it. > > -- > Kirk Brooks > San Francisco, CA > ======================= > > What can be said, can be said clearly, > and what you can’t say, you should shut up about > > *Wittgenstein and the Computer * > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** -- ************************************************* CatBase - Top Dog in Data Publishing tel: +44 (0) 207 118 7889 w: http://www.catbase.com skype: pat.bensky ************************************************* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
