[Seaside] Cooperative Multitasking (within a priority level) and other questions

[Avi Bryant]

On 5/18/05, William E Harford <seaside at harford.org> wrote:

> As I understand it Squeak has process (or is it thread) priority levels.
> A process with a higher level gets to use the CPU before that of a lower
> priority until it is done or yields but but threads in the same priority
> level are cooperative. Am I correct so far?

Yes.

> How does this affect seaside ? What if a database query takes 5 minutes
> to return will this lock the other seaside processes? What if programmer
> does something stupid and creates and endless loop (it happens)?
> Or what if there is just some chunk of code that takes a long time to
> execute. Will all other Seaside processes wait for it to complete?

While a process is waiting for the results of a database query, it
will yield to other processes - it's not busywaiting.  If you're doing
some computation that you know takes a long time, you could fork it at
a lower priority and have your Seaside process wait on a semaphore for
the results to come back.   If you create an endless loop, then yes,
without preemption you could have trouble - but not just because your
other processes are being blocked.  The most common kind of infinite
loop that I've seen, by far, is infinite recursion, and unless you
detect it and interrupt it, you'll take down the VM when it runs out
of stack space.

> If the above is true this would be unacceptable for what we do but I
> don't think it would be to hard to write some sort of preemptor (is that
> a word) . You could have a process running at a higher priority level
> giving out time slices to processes of a lower priority level; Right ?
> Is something like this needed? Should it be done at the webserver level?
> I would think it would not be to difficult to add some code to the
> webserver to handle this time slicing (when the webserver forks a child
> process to handle the request). Am I right ?

Yes, this would be possible.  I haven't had a situation where it's
necessary yet (usually the slow part is going out to a database over
the network or on disk, and there's plenty of time to switch processes
there).  But it would be easy to do if it turned out you needed it.

> Would it be possible to create a "wait" dialog/component. What I mean by
> that is a dialog that does not ask for user input but simply refreshes
> until a code block completes. Would it be as simple as creating a
> component that forks a process, sends a meta/refresh tag (along with
> some other "please wait" content), and waits for the process to
> complete ?

Yes, that sounds right.  It would be nice to get a generic version of
this (maybe even with a progress bar).

> Our org is very dependent on PDF generation and modification. We
> currently use PDFLib (pdflib.com) for most of our PDF needs. The way I
> dealt with this in the seaside app I have written is by writing small C
> programs that Squeak/Seaside makes calls out to. This is not the ideal
> situation. How hard would it be to write a Smalltalk wrapper around the
> C (or any other of the bindings) PDFLib lib. I have only found limited
> documentation primitives. Am I looking in the right place ? Is there
> some documentation that someone could point me to? I was thinking I
> could write a parser to parse the C hearer file and create an equivalent
> Smalltalk object (PDFLib uses an Object Oriented model) .

The easy way to do this is through the FFI plugin.  There's some
documentation on that here:
http://minnow.cc.gatech.edu/squeak/1414

There may well be more elsewhere, or ask on the list.

If you're worried about blocking, however, this may not be the best
way to go - calling out to a C library through FFI will block your
entire VM.  If the PDF generation takes any significant amount of
time, I would either:
- set up a separate program that listens for PDF generation requests
over a socket and returns the generated PDF (or a filename or
something)
- write a custom VM plugin that spawned a pthread to do the PDF
generation, returned immediately, and signaled a Squeak semaphore when
it was done

You may also be interested in this (somewhat rudimentary, I think) PDF
generation library for Squeak itself:

http://map1.squeakfoundation.org/sm/package/d8fd5e1a-2bb7-4c99-a77e-f945dfce01eb

Avi