(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
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
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.)
"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.
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
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 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)