Hi, One disadvantage is that there is only one execution stream with multiple windows in the one process.
If something is taking time in one window (a sequential search or sort or a even just a long method) execution will stop in all other windows, the UI will freeze etc On Sat, 3 Aug 2019 at 02:29, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> wrote: > Hi Pat, > For something like that I would think about using a palette or toolbar-ish > window as the 'root', if you will, for the UI process. > That could actually simplify things - if the user attempts to close it you > confirm they want to quit. And then you don't have to fuss around with > counting windows opened and closed. > > On Fri, Aug 2, 2019 at 9:19 AM Pat Bensky via 4D_Tech < > 4d_tech@lists.4d.com> > wrote: > > > 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 > > ********************************************************************** > > > > -- > 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 > ********************************************************************** -- Regards, Wayne ********************************************************************** 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 **********************************************************************
