World: r3wp

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 ;-)

Need to go, guys, maybe I'll came back here during the dinner so 
we can relay some questions to Carl.

Pekr, whether 1 task with 5 threads or 5 tasks (with only 1 thread 
each) is faster totally depends on your situation; your OS, your 
application (are you dependant on disk access or network access), 
bandwidth, timers, and OS task/process scheduling priority.

I missed more of the presentations than I saw, hopefully we will 
see them online somewhere soon.

Is there going to be a summary of the talks?

Reichart, we found someone that speaks faster than you. :P

 I need proof!  And, remember, I'm ALWAYS slowing my self down....I 
 consider this a challenge!  Oh, I can misspell at 120 wpm...

Was there a statement about there being video of the presentations?

Gabriele deduced that there would be since there were two cameras 
filming

FYI, this chat group is rebroadcast here: http://devcon2007.on-arran.com/chat/

I assumed nobody would mind as the group is labelled [web-public].

I'm cool.  Do you think anyone has said anything that shoud not be 
public?

Yes ... me :(

hehe