World: r3wp

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.

Thanks for including all the comments in the code too!

That's poor's man documentation but as it is a brand new framework 
and still fresh in my mind, it's better to get it writtten down now, 
even if it's a draft.

Btw, you can test this socket app using the two test script (look 
at the source code to get an idea) :
http://localhost/ws.html
http://localhost/ws2.html

I'll finish the pending items tomorrow and will try to provide a 
more fancy example by building a realtime web chat application.

Why 'deconnect rather than 'disconnect?

As a word choice that is.

Ah good one, maybe because I read 'disconnect used in a framework 
somewhere and my mind stored "deconnect" (almost french word for 
'disconnect). I'll fix that asap.

Spelling issue fixed in SVN r47.

Run Cheyenne in verbose mode (-v is enough) to see how the browser 
and the server interact.

Which version of Rebol is required? Im getting an error with View 
2.7.6.3.1

Script: "Cheyenne Web Server" (8-Mar-2009)
Script: "Untitled" (none)
make object! [
    code: 300
    type: 'script
    id: 'no-value
    arg1: 'scope
    arg2: none
    arg3: none
    near: [either root: select scope 'root-dir]
    where: 'read
]

(winxp)

same issue here

I forgot to commit one file.