World: r3wp

there will be recordings posted later on, afaik

mchean, there seems to be two cameras

Well done....thanks to Sahores Conseil, again.

yes, take us to the party :-) I will connect via Skype, so we can 
virtually drink all together :-)

i have a few minutes of recordings that i'l post to youtube later 
on too.

hmm, good tip for skype-like rebol 3 based tool :-)

Gabriele, any answer on the transparent events question ?

Sorry, was there any timeline on when we get our grubby little hands 
on R3?

Thanks to all who made the feed available!

cool thanks - wish i was in paris

End of June or a little later Brian.

ply carl with drinks and see what you can learn for us

Gregg;  Thanks.  Pacing starts now....  :)

anton, not directly, if i understand what you mean by that. i guess 
that will be in the open source part, but i'm not 100% sure.

it could be something for 3.x with x > 0

I'll bring it up again when I actually have seen R3's View system.

:)

will there be live R3 demo? ;-)

something like tryint to spawn 1000 tasks from loop in console?

ah, I forgot those are threads .... well, I suggest a refinement 
for make task. I want to choose for the task, or a thread, and task 
to be interconnected via some kind of IPC, not like launch ...

IIRC, Carl said that each new task! will cost around 10Kb of memory

that was not my question :-) The thing is, that when you launch 100 
thread for one process, you get just 1 time for your process, which 
you will divide to those 100 REBOL tasks = threads internally.

I wanted to know, if I can choose between tasks and threads

in R3, tasks are threads

imagine fast-cgi scenario, where you can choose how many instances 
of interpreter will run, and each can handle some things.

do you think it is sufficient solution then? In cheyenne, tasks are 
tasks ...

I can imagine launching e.g. 5 httpd tasks (rebol processes) each 
handling e.g. 100 connections, where 1 connection = 1 rebol task 
= 1 OS thread ...

In Cheyenne, "tasks" are processes

if it can't be scaled that way, it is imo insufficient ...

R3 will help a lot in building a much better support for CGI and 
RSP in Cheyenne.

imo Carl took the easier part - used OS threads, as those can share 
data. In the case of using processes, he would have to come with 
some IPC mechanism ... That is why I asked if 'launch is still there 
....

No, that's not the way Cheyenne works. All static HTTP requests are 
handled by only 1 process, the Cheyenne process. The "helper" tasks 
are only used to handle CGI or RSP scripts.

part=path

Sure, but do you think that e.g. 500 connections, handled by 1 rebol 
process running 500 threads will be better performer than 5 rebol 
processes handling each 100 threads?

imo those 5 separate processes get more time from OS ...

Doc;  Cheyenne is proving itself pretty worthy so far here at peoplecards.ca 
  Thanks.
Not delved too deep, but runs nice and smooth.

pekr, that depends on your os :)

Yes because context switching between processes is much more expensive 
than for threads

Brian, yes thanks, I saw your website, that's a cool concept. I''m 
glad that Cheyenne suits your needs.

actually I think that logically 5 separate tasks will handle more 
connections, as that is 5 tasks getting OS time, instead of 1 task 
getting OS time out of tens of other OS tasks running ... :-)

I hope I can do a good enough job on the actual site to keep REBOL 
is a nice light :)

I think that the OS does a fair dispatch of time between all threads 
(of same priority).

Doc - do you think that Rebollers will now turn to bad habbit = we 
start using 1 thread for 1 connection? I wonder how much more expensive 
is that in comparison to current multiplexing aproach, using just 
ports?

well, no. that's no logical consequence. both os processes and os 
threads compete for the same resources

ok, will look into scheduling. I thought that OS actually schedules 
between tasks, not caring how many threads your app does run.

I don't think so, because we had async before threading so we didn't 
took bad habits like java programmers ;-)

only that, at least with recent 2.6+ linux threading, processes are 
far more expensive to create and to switch between

Doc - so we can bet :-) I once again think, that RT will take easier 
path, so that they will rewrite protocols so that they use threads, 
no need to care about multiplexing :-)

It's too bad MS didn't support POSIX more fully.  A lo of threading 
issues got resolved
what? two decades ago.  :)

Petr, I don't think so, I guess Carl won't let that happen ;-)