[Xitami-Dev] SFL thread-safety and Java SMT

[Pieter Hintjens]

Keresztfalvi Laszlo <kereszt@iname.com> wrote:

> Is there any effort to make SFL thread safe? 

We started on this.  This is a list of the SFL modules that have been 
made thread-safe:

sflcons
sflconv
sflcvbs
sflcvsb
sflcvsd
sflcvts
sfldate
sflenv 
sflexdr
sflhttp
sfllang
sfllbuf
sfllist
sflmail
sflmath
sflmem 
sflsyst

> Maybe, I'll do it sometime if no one else :) because I just love SMT
> but it cannot use the power of multi-processors which is the default
> way to increase server capacity (eg. web or other service-like). And,
> as one of my pal says, it "linearizes" the program which means it
> serves the requests in order of arrival but with threads requests
> would see an "equally distributed" ;) response delay instead of that
> related to actual queue position... OR, you (the programmer) must
> unroll every for() into event_send(myself)..

As soon as you use multiple processes, you can benefit from multiple 
processors and less FIFO behaviour.  This is the idea behind WTP, the 
web transaction protocol included in Studio (now part of Xitami).  
We've never found the FIFO behaviour of SMT to be problematic since 
heavy work (in our business, anyhow) inevitably consists of database 
access, and this inevitably requires external processes managed by 
something like WTP.

> Further back, I made a Java SMT but without standard agents (I was no
> more time). Somebody interested? It works with Java 1.2 or 1.3.0 as
> far as I remember. I may provide it "as is" to anybody but it may
> require some review before "official" use (actually I have no time to
> do this).

What did you have in mind when you made this?  We built SMT mainly to 
allow us to develop fast servers, and C was the obvious choice for 
this.  But sometimes I regret not having used C++, since it would 
have allowed us to make the SMT abstraction much cleaner.

-
Pieter Hintjens
iMatix Corporation