[Seaside] Long running tasks

[Sven Van Caekenberghe]

> On 15 Mar 2021, at 16:30, Esteban Maringolo <emaringolo at gmail.com> 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 <aaron at chatnbike.com> 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
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside