1. has already been covered quite comprehensively by JPR; you got one half of the solution (chunking the task), the other half is that the worker calls itself recursively, instead of waiting instruction to drip. on a related point, when calling a worker (other than yourself), it is important to take into account that workers may finish their task in any order, so you need to coordinate for than when delegating a task to multiple workers.
2. I guess is will have to be managed logically by disabling the UI, perhaps by display a (translucent) image over the entire form. > 2016/09/06 6:53、Cannon Smith <[email protected]> のメール： > > 1. How can the user cancel some work that is being done? If I send a > message using CALL WORKER to cancel the work, I don't think it gets the > message until the work is done. Is it possible for a worker process to > periodically check for new "messages" while in the middle of work? Or would > the window itself have to chop up the work in some manner and only send the > worker a bit at a time? That seems much slower as the two processes would > have to have back and forth communication for each “block” of work. > 2. By shifting the work to a worker process, the UI on the window stays > active. In some cases this is desirable, but in others you may not want the > user to be able to click or type anything in that window until the work is > done. Something to consider. 宮古 啓介 セールス・エンジニア 株式会社フォーディー・ジャパン 〒150-0043 東京都渋谷区道玄坂1-10-2 渋谷THビル6F Tel: 03-6427-8441 Fax: 03-6427-8449 [email protected] www.4D.com/JP ********************************************************************** 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] **********************************************************************
