Features Download
From: Dossy Shiobara <dossy <at> PANOPTIC.COM>
Subject: Re: AOLserver's documentation woes and its future
Newsgroups: gmane.comp.web.aolserver
Date: Tuesday 5th September 2006 15:41:40 UTC (over 11 years ago)
(Apologies for the long email ahead ... but, I think it's worth a quick

On 2006.09.05, Rick Gutleber  wrote:
> Support for more popular languages (come on, let's say it together, I 
> know it's hard, but "Tcl is not popular") is probably the most useful 
> long-term technical change that can be made.

Of course, the more popular languages weren't implemented with
embeddability (embedibility?) in mind.  Tcl is one of the only mature
languages that can be safely embedded in a multi-threaded application.

Specifically, what I mean is, Tcl is one of a few languages that can
have multiple interpreters in the same process space executing
concurrently in multiple threads.

Python can be embedded, but according to this:


    8.1 Thread State and the Global Interpreter Lock

    "The Python interpreter is not fully thread safe. In order to
    support multi-threaded Python programs, there's a global lock that
    must be held by the current thread before it can safely access
    Python objects. [...]"

A global lock?  There goes scalability and the benefits of embedding
Python.  (You'd be better off running it in a separate process ala
FastCGI, AOLserver would gain no performance by embedding it, only

Same problem with Ruby:


    "ruby is not thread-safe. If you embed ruby into a multi-threaded
    application then you will need to semaphore protect all access to
    ruby. Warning: Insufficient semaphore protection can be hard

So, they're pointing out the need for a global lock, too.  What's worse,
the Ruby interpreter uses global variables to manage interpreter state,
so even if you did embed it and use a global lock, you couldn't spin up
two instances of the interpreter in the same process, anyway!

PHP isn't even worth considering, really:

    Re: [PHP-DEV] Re: PHP and Apache2

    "The major feature that draws people to Apache2 is threading. [...]
    However, on UNIX there are a lot of basic libraries where thread
    safety is an unknown.  [...]
    And yes, you could use the prefork mpm with Apache2 to avoid the
    threading, and yes you could use a standalone fastcgi mechanism to
    avoid the threading, but you are going out of your way to avoid the
    defining characteristic of the web server you have decided to use."

Rasmus makes it very clear that the reason PHP is so popular and
powerful is its large list of third-party extensions that add a lot of
"out of the box" functionality for PHP developers.  However, it's that
same attribute of PHP that keeps it from playing nicely, embedded in a
multi-threaded application.
Lets not forget this, too:


    "Jani Taskinen, one of the lead developers of the Zend Engine (the
    engine that powers PHP), as well as a lead developer for the thread
    safety system and other core components of the PHP project, has quit
    in a relatively cryptic message to the php-internals mailing list.
    Jani has been involved with PHP for about 6 years and his loss will
    undoubtedly be a big blow for the PHP project."

It'll be interesting to see where the future of PHP takes it.

Now, lets look at Perl:


    "Now suppose we have more than one interpreter instance running at
    the same time. This is feasible, but only if you used the Configure
    option -Dusemultiplicity or the options -Dusethreads -Duseithreads
    when building perl. [...]

    Using -Dusethreads -Duseithreads rather than -Dusemultiplicity is
    more appropriate if you intend to run multiple interpreters
    concurrently in different threads, because it enables support for
    linking in the thread libraries of your system with the

Oh, nice.  I don't see any mention of using a globally shared lock to
prevent two Perl interpreters running concurrently.  (This could just be
an omission from the docs, but I have the feeling it's not the case.)

So, of the "languages more popular than Perl" being Python, Ruby, PHP
and Perl ... Perl is the only suitable candidate for replacing Tcl in

Considering that Perl is no longer the "flavor of the day" and has been
replaced by Python and Ruby amongst the "language geeks" and PHP amongst
the unwashed masses ... who really wants to go replacing AOLserver's
embedded Tcl with embedded Perl?  How many months or years before people
see Perl like they see Tcl today (not popular, etc.)?

The irony here is so few people have even heard of Tcl that if it was
evangelized and marketed correctly, it could be brought to the
marketplace as a "new" language to replace Ruby and Python and PHP.
Write a slew of books, release a mound of free Tcl code and add simple
enhancements to Tcl like closures/lambdas and other language features
that'll make the language geeks go "ooh!" and the unwashed masses will
download all the free code they need ...

... and then the cycle starts all over again.

After having said all this, I would like to explore the idea of
Server-side JavaScript (SSJS):


Netscape took a shot at this with its LiveWire stuff back in
1996.  Now that it's 10 years later, could it be the right time to try
again?  (I wouldn't try to re-implement LiveWire, but use what we've
learned about embedding a scripting language inside a webserver and use
JS as the language.)

    SpiderMonkey: JavaScript C Engine Embedder's Guide

    "The run time is the space in which the variables, objects, and
    contexts used by your application are maintained. A context is the
    script execution state for a thread used by the JS engine. Each
    simultaneously existent script or thread must have its own context.
    A single JS run time may contain many contexts, objects, and

I'd like to work on an AOLserver module and ADP parser (extend the fancy
parser to recognize "") to embed SpiderMonkey, as a start.
I'd argue that there's more JavaScript expertise out there today than
there is Java, PHP, etc. because with the rise of RIA's and AJAX
techniques, regardless of what backend language you use, you still have
to use some amount of JavaScript.  To me, it makes sense to leverage
that same JS knwoledge (and code!) on the server side, too.

IMHO, this change could put AOLserver back in the beauty pageant.

As always, I welcome any comments or criticisms or flaming of my
half-baked off-the-cuff email-to-the-whole-list ideas I presented here.
I know there's plenty of them ... :-)

-- Dossy

Dossy Shiobara              | [email protected] | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)
CD: 3ms