[Seaside] Serving files
cdshaffer at acm.org
Thu Oct 12 03:09:18 UTC 2006
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
My tests show differently:
> 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.
More information about the Seaside