[Pharo-project] leaking semaphores

Guido Stepken gstepken at googlemail.com
Thu Mar 1 05:41:37 EST 2012


No. I just tried to teach Pharo to do several things in parallel: Seaching
stings in several 1 GB files, opening and reading several databases at once
in parallel, handing results over sockets to several clients. Try it
yourself.
Whatever you do with Pharo, you won't get any smooth IO, even if you use
COGMT. Smalltalk code is not yet adapted, it seems. Same with
eventhandlers. Try editing while copying and filtering a file in
background. Happy waiting!

I had much success with Smalltalk MT, LUAJit, medium success with node.js
...

Don't get me wrong, but business develops to realtime filtering of
concurrent information streams coming from different sources (twitter,
facebook, mail, irc, p2p, databases, homepages, rss, XML, Soap ) and that
intelligently presented in realtime on my Desktop.

We did intensive testing of several interpreters.

I personally really prefer Pharo, because it offers a outstanding, very
complex construction kit for doing marvellous things, beginning from
"abstract connectors" that combine filters with editors with gui, web,
streams, databases, over to very good IDE up to certain (decreasing)
compatibility to squeak and its mass of "toy apps".

I think, that, when a deeper understanding of how to acheive parallelism,
realtime, concurrency comes to Smalltalk programmers (not just starting
coroutines and hoping, the kernel gets it right, claiming everything is
multithreaded), Pharo very soon could be business ready! :-)

And it is good to understand, *why* Wikipedia now uses LUAJit (a highly
dynamic language, like Smalltalk), Blizzard (World of Warcraft), Steam
(realtime control of complex game worlds) use LUAJit, EVE uses Stackless
Python with continuations. Smalltalk would be very well suited, but its
implementations are missing important features, realtime qualities, real
concurrency, not just one at the surface, claiming apps being
"multithreaded".

Seaside, e.g. immediately drops to under 1/second, at even 10 simulaneous
clients, when data comes from SQL or even OODB, means case of cache misses.
Pharo becomes unresponsive.

For me, good architectures can be recognized, when they smoothly go on
serving, even at 50 times overload, still keeping small memory footprint.
Compare to Linux at high loads (sshd, telnetd not answering) and FreeBSD
(you can still login, even if 50.000 clients connected).

You might still laugh at me... i don't.

Have fun, Guido Stepken
Am 01.03.2012 10:29 schrieb "Henrik Johansen" <henrik.s.johansen at veloxit.no
>:

>
> On Mar 1, 2012, at 10:03 AM, Guido Stepken wrote:
>
> As long as GC, recompile, (see blocked UI during updates), ffi database
> drivers completely block Smalltalk execution or do not access external
> databases smoothly in parallel (also see async I/O, MP) i see only one
> laugh here - that's indeed you!
>
> Have fun!
>
> Guido Stepken
>
>
> Aaah, the good ol' "If you can't hit with a rifle, switch to a shotgun"
> approach, haven't seen that in a while.
>
> Have fun!
> Henry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120301/5975ece2/attachment-0001.html>


More information about the Pharo-dev mailing list