Hi Miyako, I think that makes sense, but let me make sure I understand. Let’s say a window needed a worker to process 1000 items in a loop. You are saying that the worker’s code should be constructed so that the window can pass the 1000 items to it in one message and then the worker will process, say, 10 items and then send a message to itself (CALL WORKER?). In most cases the worker will receive this message and know to process the next 10 items. But if the window had sent a cancel message in the mean time, that will be the message that comes off the stack first. So the worker will cancel the job. And I guess it has to be smart enough to ignore the last message it sent to itself. Is that correct?
Thanks for the insight. -- Cannon Smith Synergy Farm Solutions Inc. Hill Spring, AB Canada 403-626-3236 <can...@synergyfarmsolutions.com> <www.synergyfarmsolutions.com> > On Sep 5, 2016, at 6:43 PM, Keisuke Miyako <keisuke.miy...@4d.com> wrote: > > 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. ********************************************************************** 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 **********************************************************************
