Long running tasks
Locked
 
|
Hi,
Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow. Does Seaside have a pre-baked solution for this? If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject: In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline. I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link. These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters. I’ve setup a public demo app / repo to test out these concepts: It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk? Thanks in advance for any advice you may have, — Aaron _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi
> On 14. Mar 2021, at 19:40, Aaron Rosenzweig <[hidden email]> wrote: > > Hi, > > Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow. I've written something like that for SqueakSource3 about 10 years back. The idea involved: On Squeak (or Pharo) - an ever running background Process with a loop and - a shared queue and - the Seaside-Processes putting work items there. - the background process picks up items off that queue. On GemStone: - a separate "Service-Gem" that loops on a - shared (reduced-conflict) Queue - the Seaside gem(s) committing items to that queue and - the service gem handling them. Dale Henrichs explained that bit quite well actually here: https://github.com/GsDevKit/ServiceVM Hope that helps. -Tobias > > Does Seaside have a pre-baked solution for this? > > If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject: > http://onsmalltalk.com/polling-for-long-running-processes > http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk > > In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline. > > I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link. > > These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters. > > I’ve setup a public demo app / repo to test out these concepts: > > https://github.com/recurve/ScriptaculistPharoHeySql/ > > It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk? > > Thanks in advance for any advice you may have, > — Aaron > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks Tobias,
That’s a great writeup - I like the looks of WADelayedAnswerDecoration discussed there too! Thanks for the tip.
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Aaron
> On 14. Mar 2021, at 21:06, Aaron Rosenzweig <[hidden email]> wrote: > > Thanks Tobias, > > That’s a great writeup - I like the looks of WADelayedAnswerDecoration discussed there too! Thanks for the tip. Glad to help. For the last question you had, do you mean something like Processor yield or 10 seconds delay wait ? Best regards -Tobias > > >> On Mar 14, 2021, at 3:17 PM, Tobias Pape <[hidden email]> wrote: >> >> Hi >> >>> On 14. Mar 2021, at 19:40, Aaron Rosenzweig <[hidden email]> wrote: >>> >>> Hi, >>> >>> Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow. >> >> >> I've written something like that for SqueakSource3 about 10 years back. >> >> The idea involved: >> On Squeak (or Pharo) >> - an ever running background Process with a loop and >> - a shared queue and >> - the Seaside-Processes putting work items there. >> - the background process picks up items off that queue. >> >> On GemStone: >> - a separate "Service-Gem" that loops on a >> - shared (reduced-conflict) Queue >> - the Seaside gem(s) committing items to that queue and >> - the service gem handling them. >> >> Dale Henrichs explained that bit quite well actually here: >> https://github.com/GsDevKit/ServiceVM >> >> Hope that helps. >> -Tobias >> >>> >>> Does Seaside have a pre-baked solution for this? >>> >>> If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject: >>> http://onsmalltalk.com/polling-for-long-running-processes >>> http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk >>> >>> In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline. >>> >>> I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link. >>> >>> These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters. >>> >>> I’ve setup a public demo app / repo to test out these concepts: >>> >>> https://github.com/recurve/ScriptaculistPharoHeySql/ >>> >>> It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk? >>> >>> Thanks in advance for any advice you may have, >>> — Aaron >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Aaron Rosenzweig
http://smalltalkhub.com/pdebruic/ThreadPool/
Is the code from Ramon's blog post & works with Seaside and Pharo/GemStone and I think Squeak. Aaron Rosenzweig wrote > Hi, > > Last I checked, Seaside is single-threaded which is a “good thing.” That > said, it implies that every user action must return quickly… perhaps no > longer than 1 second. If the action takes longer, a chain reaction starts > to form from multiple “simultaneous” users (not really at-the-same-time > users, they queue up with the single thread). There are times, in apps > I’ve written, where the act of clicking a link (or button) is expected to > take 10 minutes (sometimes half hour). During this time we want to fork a > thread to do the big task (like generate a report) that doesn’t tie up the > main thread. This way we can poll every 2 seconds to ask “are you done > yet?” with a progress bar and then ultimately bring the user back to the > normal flow. > > Does Seaside have a pre-baked solution for this? > > If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been > able to find about the subject: > http://onsmalltalk.com/polling-for-long-running-processes > <http://onsmalltalk.com/polling-for-long-running-processes> > http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk > <http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk> > > In his case, he wanted a page to load immediately but then have a handful > (or more) ajax requests running in the background pinging other servers to > tally prices for a travel quote site. Sort of like those interlaced GIF > images back in the day, his page pops with basic information then > progressively renders other parts. So his example has maybe 10 threads > forked for one page to fully load and shows updates inline. > > I was thinking more of one page WAProgress (I made that up) with one > forked thread that monitors its execution and returns when it either > completes, errors, or the user clicks a cancel link. > > These are things baked into WebObjects (NeXT / Apple) and is what my > buddies and I use daily. We are tiptoeing around the idea of starting new > web development projects with Smalltalk / Seaside and testing the waters. > > I’ve setup a public demo app / repo to test out these concepts: > > https://github.com/recurve/ScriptaculistPharoHeySql/ > <https://github.com/recurve/ScriptaculistPharoHeySql/> > > It’s an address book application. What I’ll do is modify the delete of a > contact to fork and render the Progress component and programmatically > make the delete slow to show the feature. By the way, how do I do the > equivalent of “Thread.sleep()” in Smalltalk? > > Thanks in advance for any advice you may have, > — Aaron > _______________________________________________ > seaside mailing list > seaside@.squeakfoundation > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Sent from: http://forum.world.st/Seaside-General-f86180.html _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks Paul for the link to smalltalk hub with Ramon’s code from the blog post :-)
Also thanks Tobias for the “10 seconds delay wait" syntax :-) That’s probably what I was looking for. I had seen a concurrency book for Pharo that talked about yield but that doesn’t pause the thread, just makes it lower priority. Thanks everyone :-)
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Aaron Rosenzweig
Hi all,
I don't want to hijack this thread, but in all these years my understanding was that even though most Smalltalks are single threaded, they can handle HTTP requests concurrently (as long as there is no other I/O thing blocking, like DB, FS, etc.) because the socket handling is usually handled multithreaded or non-blocking by the VM, in Pharo the ZnMultiThreadedServer is there for a reason. With that assumed, Seaside implements a particular session mutex to block multiple requests from the same session to execute concurrently (possibly messing not just the app state, but the continuations for that session). So my conclusion has always been that as long as there is no blocking at the VM level, Seaside can handle requests from different sessions concurrently. Is that correct or I got it wrong all this time? Best regards! Esteban A. Maringolo On Sun, Mar 14, 2021 at 3:40 PM Aaron Rosenzweig <[hidden email]> wrote: > > Hi, > > Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow. > > Does Seaside have a pre-baked solution for this? > > If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject: > http://onsmalltalk.com/polling-for-long-running-processes > http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk > > In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline. > > I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link. > > These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters. > > I’ve setup a public demo app / repo to test out these concepts: > > https://github.com/recurve/ScriptaculistPharoHeySql/ > > It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk? > > Thanks in advance for any advice you may have, > — Aaron > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Long running tasks
|
|
> On 15 Mar 2021, at 16:30, Esteban Maringolo <[hidden email]> wrote: > > Hi all, > > I don't want to hijack this thread, but in all these years my > understanding was that even though most Smalltalks are single > threaded, they can handle HTTP requests concurrently (as long as there > is no other I/O thing blocking, like DB, FS, etc.) because the socket > handling is usually handled multithreaded or non-blocking by the VM, > in Pharo the ZnMultiThreadedServer is there for a reason. > > With that assumed, Seaside implements a particular session mutex to > block multiple requests from the same session to execute concurrently > (possibly messing not just the app state, but the continuations for > that session). > > So my conclusion has always been that as long as there is no blocking > at the VM level, Seaside can handle requests from different sessions > concurrently. > > Is that correct or I got it wrong all this time? I think you are right, at least that is also my understanding. Every concurrent request is handled in its own worker thread/process. These are all at the same priority. As long as there is not one of them that locks up the whole VM, by doing a long FFI call for example, they will cooperate and execute concurrently. That is why socket IO (like for talking to other services or databases) is so good: it naturally creates waiting/switching/yielding opportunities and does normally not lock up things. > Best regards! > > Esteban A. Maringolo > > On Sun, Mar 14, 2021 at 3:40 PM Aaron Rosenzweig <[hidden email]> wrote: >> >> Hi, >> >> Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow. >> >> Does Seaside have a pre-baked solution for this? >> >> If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject: >> http://onsmalltalk.com/polling-for-long-running-processes >> http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk >> >> In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline. >> >> I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link. >> >> These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters. >> >> I’ve setup a public demo app / repo to test out these concepts: >> >> https://github.com/recurve/ScriptaculistPharoHeySql/ >> >> It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk? >> >> Thanks in advance for any advice you may have, >> — Aaron >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |