[Seaside] Serving files

[Philippe Marschall]

2006/10/12, David Shaffer <cdshaffer at acm.org>:
> David T. Lewis wrote:
> > On Wed, Oct 11, 2006 at 01:15:37PM -0400, David Shaffer wrote:
> >
> >
> > I don't think that blocking IO has anything to do with why Squeak
> > does or does not make a good web server, and it's only incidentally
> > related to the process/thread model in Squeak. But for what it's
> > worth:
> >
> My tests show differently:
>
> http://minnow.cc.gatech.edu/squeak/539
>
>
> > To set a file stream for non-blocking reads, the required
> > primitives are in OSProcessPlugin (distributed with Unix VMs, or
> > roll your own for Windows), and used in OSProcess (Squeak Map).
> > See e.g. OSProcessAccessor>>setNonBlocking:. This is applicable
> > to OS pipes and other file-like external resources, as well as
> > to conventional files.
> >
> As I said in my post, it can be done but ModFile doesn't currently do
> it.  My wiki (above) page provides a "proof of concept" version that
> does just this but requires a VM change to be able to compute the file
> size in a non-blocking way.  There are other blocking file I/O calls
> involved in servicing a web request as well.  I suspect those need to be
> dealt with to get maximum performance.  Still, just asynchronous file
> I/O provides a huge improvement (see my benchmarks on that page).
>
> This might be the appropriate time to mention that "hacking" at classes
> like ModFile to make them perform asyc file I/O isn't solving the larger
> problem: Squeak file I/O needs to not block the VM.  There are many web
> applications that do file I/O and having the default behavior be VM
> blocking will cause headaches for people developing these applications.
>
> > None of this has anything to do with the process or threading model
> > of Squeak, other than the fact that if you don't set non-blocking
> > behavior on files (and sockets), you will lock up the VM on certain
> > read operations.
> >
>
> Yes, that was exactly my point.  The first response in this e-mail
> thread brought the threading issue in and I wanted to point out that
> this isn't the problem.

If two different processes want to access the same file (each creating
its own filestream !) things can get fucked up because the file
registry is not thread-safe.
This isn't theoretical. This happened on one of our production applications.

And about the OSProcessPlugin, it deadlocks from time to time. This
again happened in one of our production applications too and is the
reason why Avi doesn't use it for DabbleDB and uses cgi scripts
instead.

Philippe