World: r3wp

This is what I'm looking to do.

- A client connects via websocket.

- Client sends message "a". The server runs the following

forever[
n: read http://cheyenne-server.org/blog.rsp
prin n
wait 1
]
 
- Client sends second message "b". The server runs the following

forever[
x: read http://rebol.com/cgi-bin/blog.r
prin n
wait 2
]

These loops should be non-blocking.

- ws:// and wss:// need to be  Uniserve services

- the service should simply receive incoming messages and pass on 
to a non-blocking handler, and receive repsonses (optional) to pass 
back to the client
- a method to "access to all client ports" as you mentioned

Terry, got drag working..very cool

Alan, it's rather trivial to track the position of the box relative 
to the screen, and pass that on via the websocket. 

Something like a live chessboard could be created in 20 lines of 
javascript (using JQuery lib)

Terry, in the ws framework I'm working on, there will be a timer 
system with an on-timer handler that you can use for server-side 
events (timer ticks are produced by my scheduler library http://softinnov.org/rebol/scheduler.shtml
recently integrated in Cheyenne).

well, is that not the time to carry on R3, Doc ?
You can use tasks advantageously for such job.

btw what is missing in R3 that you can't carry on Cheyenne ?

Stability (still alpha), feature-completeness (at least R2 level, 
including /library) and last but not least, time and money.

Doc, the scheduler dialect is great. Wonder why it wasn't thought 
of before.
I was considering purchasing a copy of nnCron this week.

I didn't knew that R3 tasks support was finished?

Didn't know either, but i tried some days ago and it works

Terry: I've asked myself the same question while implementing this 
scheduler lib this summer, I couldn't believe that no one did it 
before in ten years...that the bad side of having a micro-community 
(one of the good side is not seeing guys like Ratio popping up too 
often).

Yeah, it's Rebol's primary failing... lack of community size. Same 
reason i switched from Mootools JS lib to JQuery.

Steeve: what works? Launching a task? That's not enough, we need, 
at least, a way to control tasks execution and a safe & efficient 
mean to share values...Unless I've missed something, it's still not 
usable.

AFAIU but I might not have the latest news, Carl postponed full tasking 
support to R3.1, so there's still time.

The list for 3.0 is not final. What I don't like even more is kind 
of lack of leadership. I described it in my marketing related docs. 
There is some kind of imo wrong attitude towards finishing beta - 
some things were moved into "it might be delivered by community" 
category, and it as well might mean - never delivered ...

http://www.rebol.net/wiki/What_makes_a_good_beta#Wrong_attitude_towards_finishind_R3.3F

I'll find what Carl said about task! .... I agree with Doc, that 
it is far from finished ...

Here's some prior info on tasks gathered from Carl's replies in September:


The model is: threaded CPU, shared memory, shared symbol space, shared 
system function space, separate evaluation stacks, separate user 
contexts.


Intertask comm is via Ports. Sync is via ports. BTW, "ports" does 
not need to mean "sockets".


The host level can provide a more direct mechanism for inter-task 
sync and comm.

I'm not a fan of locking, but sometimes it's necessary. Otherwise, 
mods can be "cloned" for multi-task uniqueness.

what is the interest of intertask comm if we got shared memory ?

Actually, if i'm not wrong. Tasks are switched every 0.001 second 
(wiich might be too slow for huge task handler, like uniserve).

The only thing missing currently, is the ability to switch tasks 
prior the next switch event.

A RESUME or SWITCH function, could allow that. To switch to the next 
waiting task in the queue immedialty.

On which OS are you testing?

Vista

what is the interest of intertask comm if we got shared memory ?

Shared memory needs coordination to manage the shared access. Intertask 
communication allows tasks to share less, which makes the whole more 
scalable. Plus it can turn into interprocess or intercomputer communication 
without changing algorithms, which makes it even more scalable.

Threading on POSIX is unimplemented. If it works on Windows, it's 
by accident. It's unfinished and untested

Yes, but one of us (not me) can help work on it.

Start by providing the __attribute__ for thread-locals, assuming 
that the .so supports that.  If not, we'll need to move the thread 
local vars into a struct, and allocate it dynamically.  However, 
we'll still need at least one thread-local from the host kit side, 
to provide the base pointer for each thread.

Carl - you said:


The model is: threaded CPU, shared memory, shared symbol space, shared 
system function space, separate evaluation stacks, separate user 
contexts.


Intertask comm is via Ports. Sync is via ports. BTW, "ports" does 
not need to mean "sockets".

Does it mean the code is in the Host, not in the kernel?

Yes, most of the work is in the Host.

However, the kernel uses thread-local variables.... which are not 
currently enabled on Posix builds.

without task!, Doc can't start moving Cheyenne (our premium product) 
to R3. He recently added early support for websockets protocol ....

Pekr, I'm not so sure that's true.

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

We have the old R2 IPC code here that we could use for quick messages 
between procs.

I know what you mean. It could be ported, but model would be the 
same as in R2 - multiplexing, spawned tasks. But I think Doc might 
be interested in using threads instead, so my bet is he will wait, 
until it gets finished ...

Yes, I think that ppl expect task having some schemes around them, 
to allow IPC. IMO what was wrong with R2 was, that we (as a community 
plus RT) never "standardised" on such things ...

Of course, the other benefit is that in sharing symbols, we could 
pass full blocks (not text) between task!s.

So most ppl (let's say average coders) ended up with the possibility 
to spawn new R2 processes, but not knowing how to properly sync them 
to communicate ...

Well, I'd like to see a lot more standards in R3. At least, I'm planning 
a few std modules for all the common stuff we use here.

I think that many ppl here think that the priority of importance 
is:

- host release
- host support of View (merge of DELECT and command type)
- Extensions supporting Devices, callbacks
- tasking, IPC
then beta ....


If you postpone anything from above to 3.1, some ppl will wait for 
3.1 ... do you want to bet with me? :-)

I think you are correct. But, as soon as we are confident in 3.0, 
we should put it out, even if missing a few features.

For example, the new REBOL.com website runs on R3 scripts.

I am fully for R3, and to not look back. Did you notice, how positive 
reactions you got to initial Host release? Hopefully that cooperative 
aproach works. But in some areas, we NEED design leadership. So - 
that is why I put a note to my "marketing" related docs, stating 
that simply transferring the responsibility to the community, might 
not see the features delivered.


So - maybe you could blog a bit - hey, guys, tasking's next. If you 
want it, try to prepera following details for me .... 1) 2) 3), etc.

I totally agree with you here.  In fact, I won't accept anything 
that does not meet my requirements.

yes, so hopefully you can now understand, why I objected to your 
(taken from Project plan) words: "Also, this list is only for R3 
core operation and does not include community-based projects such 
as graphics, GUI, protocols, documentation, and other features that 
can be developed externally, depending on the needs of the community."

I can (well, maybe I even can't :-) imagine, how picky you might 
be about the code quality. So it is really not imo enought to state 
- hey, guys, here's host code, who does the best task implementation, 
wins a bottle of Rebol wine :-)

I know that BrianH might not agree with me. Community can do some 
research, reference implementation, but I would expect stuff like 
tasks being DESIGNED (not implemented) by the author of first multitasking 
operating system himself :-)

OK, going to sleep, 2:30 here ... and soon enough Doc might jump 
here, that I turned his group off-topic ...

Steeve seemed to imply that R3 has its own thread scheduler. Is that 
true?

No.