[Seaside] Serving files

David Shaffer 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
> 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.

David



More information about the Seaside mailing list