Wayne, That's true but it's easy to hand off tasks like that to Workers. And the worker uses CALL FORM to hand back the results.
On Fri, Aug 2, 2019 at 10:22 AM Wayne Stewart via 4D_Tech < 4d_tech@lists.4d.com> wrote: > 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 > ********************************************************************** -- 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 **********************************************************************
