World: r3wp

Btw, I wrote a "intranet voting system" using cheyenne & rsp just 
in 2-3 hours (with login, user management, messaging, voting, product 
upload etc.). That was a real fun to use rsp.

session-problem

: if you mean the issue raised by Janko and fixed a few days ago, 
it's in the SVN repository: http://code.google.com/p/cheyenne-server/

Intranet voting in RSP: "simple things should be simple to do." ;-)

Doc: yes, I meant that, you sent me the fixed version r40.

Right, I forgot...

Anyone know if RT is looking at using Cheyenne on the backend?

Also, is Cheyenne currently being ported to R3?

1) Don't know.
2) No, see yesterday's discussions here.

Doc - sorry to flood your channel here, but I tried to convince Carl 
to finish concurrency, while he was still here :-)

I thought that 10 other users might help me to convince him, but 
noone helped :-)

The only advantage of task! is about 1MB of memory. Otherwise, you 
can fire up multiple R3 processes and communicate between them.

 <- I thought task! would make things like that much simpler. I've 
 always found that using multiple processes was too complicated, unless 
 you have a powerful tool at hand to handle this for you.

Henrik - yes, just read the discussion. Carl claimed, that RT has 
long time the code to IPC between processes. I objected, that no 
such code was standardised over-time, so that is maybe a reason, 
why ppl do wait for tasks. We await stuff like ipc:// scheme, etc.

also - isn't there difference between tasks and threads and how they 
scale in multi CPU/multicore environments?

A task is an OS thread in R3. Carl just confirmed that here yesterday

yes, I know. But he also asked, why don't we use OS tasks, via 'launch 
funciton probably, and such solution would mean OS tasks, not threads. 
My question was plainly theoretical - I was curious, what scales 
better in modern multicore envrionments - tasks, or threads, or it 
does not matter?

Those are called processes

Pekr: no problem. Cheyenne is one of the application that would benefit 
the most from threads.


IPC between processes can't compare to shared memory between threads. 
With processes, you need to serialize values, transfer them (multiple 
memory copies or worth using a disk file), then LOAD them back. With 
shared memory, you just pass a memory reference to the value and 
you ensure (using a sync mechanism) that no concurrent writes occur 
on that value. It's at least a magnitude faster and uses so much 
less memory.

hmm, how is that Amiga tasks were so fast? Didn't they share some 
space too? Well, but AOS is not memery protected, so most probably 
you are right, that in most OSes, processess are isolated ...

thanks for explanation ....

In AmigaOS, there's no difference between processes and threads, 
hence tasks. The major difference is that processes have their own 
memory space, while threads share memory within a process. AmigaOS 
has no protected memory, so there is only one task concept

Needing to advocate for multithreading support in a programming language 
two days from 2010 is almost...anachronic.

Almost?

I'm trying to say it softly.

So far, REBOL has been quite like Amiga: one big shared memory space

To be fair, you also still have to beg for multithreading in operating 
systems and applications

Doc - we all know, that it is planned, no? We just don't screem loudly 
enough, that R3 released without finished concurrency concept, is 
not worth calling a beta ...

Doc: Did you see my earlier question about whether Cheyenne has an 
equivalen to mod_expires?

PeterWood: I've missed it. There's a contributed mod-expire by Will.

I'm a bit worried, os threads with shared memory isn't a good approach 
IMHO. Such approach is prone to dead lock and oscure bug.

I would prefer light threads with no shared mem, only with message 
passing

The message passing will be there, so the issues will be limited

A language VM can have much better control over threading than a 
conventional OS

REBOL's own form of lightweight protected memory will be there: contexts

Thanks Doc.

Look in %Cheyenne/mods/mod-expire.r

Cheyenne needs a message broker for websockets... task-master?

well, to counter the dead-locks, we could have a new sort of attribute 
for functions like [ATOMIC] or [SINGLE].
That will prevent a function to be interrupted by other tasks.

or maybe 2 new functions, to disable and enable tasks interrupts, 
would be enough (like in some ASM)

or FORBID :-)

Davide: dead lock is not a fatality, threading support can be implemented 
correctly to avoid such issue (but with possible restrictions). As 
usual in software design, it's a matter of tradeoffs.

Btw, both OS threads and light threads are desirable and useful features, 
IMO.

yes, I agree on OS and light threads (coroutines or something)

Terry, wait to try the new web socket framework I'm working on. It 
should be ready tonight (if I find time to finish testing and debugging).

Sitting on the edge of my chair :)

me too :)

SVN r46 : web socket application framework released.

It's unfinished, but I try to follow the motto: release early, release 
often. At least, you can get a taste of how it looks like. Simple 
 test application with lots of comments here : http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/www/ws-apps/ws-test-app.r

It's basically an addition to the supporting code added a couple 
of days ago. It defines an application container that is loaded in 
Cheyenne main process to interact closely with all connected clients 
while permitting background tasks execution using the initial RSP 
script as target (%www/ws.rsp in the example). No change on the RSP 
side.

I have to make some time to play. Very cool Doc. Thanks for posting 
early and often.

There's also now the ability to define a timer per socket application 
to generate server-side events (powered by my scheduler library).

Thanks Gregg for the support, the more eyes on this, the better it 
will be.