[Seaside] Long running tasks

[Esteban Maringolo]

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 <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