r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[DevCon2007] DevCon 2007

Gabriele
10-May-2007
[1219]
it could be something for 3.x with x > 0
Anton
10-May-2007
[1220x2]
I'll bring it up again when I actually have seen R3's View system.
:)
Pekr
10-May-2007
[1222x3]
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 ...
Dockimbel
10-May-2007
[1225]
IIRC, Carl said that each new task! will cost around 10Kb of memory
Pekr
10-May-2007
[1226x2]
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
Dockimbel
10-May-2007
[1228]
in R3, tasks are threads
Pekr
10-May-2007
[1229x3]
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 ...
Dockimbel
10-May-2007
[1232]
In Cheyenne, "tasks" are processes
Pekr
10-May-2007
[1233]
if it can't be scaled that way, it is imo insufficient ...
Dockimbel
10-May-2007
[1234]
R3 will help a lot in building a much better support for CGI and 
RSP in Cheyenne.
Pekr
10-May-2007
[1235]
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 
....
Dockimbel
10-May-2007
[1236]
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.
Pekr
10-May-2007
[1237x3]
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 ...
btiffin
10-May-2007
[1240]
Doc;  Cheyenne is proving itself pretty worthy so far here at peoplecards.ca 
  Thanks.
Not delved too deep, but runs nice and smooth.
Andreas
10-May-2007
[1241]
pekr, that depends on your os :)
Dockimbel
10-May-2007
[1242x2]
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.
Pekr
10-May-2007
[1244]
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 ... :-)
btiffin
10-May-2007
[1245]
I hope I can do a good enough job on the actual site to keep REBOL 
is a nice light :)
Dockimbel
10-May-2007
[1246]
I think that the OS does a fair dispatch of time between all threads 
(of same priority).
Pekr
10-May-2007
[1247]
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?
Andreas
10-May-2007
[1248]
well, no. that's no logical consequence. both os processes and os 
threads compete for the same resources
Pekr
10-May-2007
[1249]
ok, will look into scheduling. I thought that OS actually schedules 
between tasks, not caring how many threads your app does run.
Dockimbel
10-May-2007
[1250]
I don't think so, because we had async before threading so we didn't 
took bad habits like java programmers ;-)
Andreas
10-May-2007
[1251]
only that, at least with recent 2.6+ linux threading, processes are 
far more expensive to create and to switch between
Pekr
10-May-2007
[1252]
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 :-)
btiffin
10-May-2007
[1253]
It's too bad MS didn't support POSIX more fully.  A lo of threading 
issues got resolved
what? two decades ago.  :)
Dockimbel
10-May-2007
[1254x2]
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.
Anton
10-May-2007
[1256]
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.
Brock
10-May-2007
[1257]
I missed more of the presentations than I saw, hopefully we will 
see them online somewhere soon.
Graham
10-May-2007
[1258]
Is there going to be a summary of the talks?
[unknown: 9]
10-May-2007
[1259x2]
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?
Henrik
10-May-2007
[1261]
Gabriele deduced that there would be since there were two cameras 
filming
Chris
10-May-2007
[1262x2]
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].
[unknown: 9]
11-May-2007
[1264]
I'm cool.  Do you think anyone has said anything that shoud not be 
public?
Graham
11-May-2007
[1265]
Yes ... me :(
[unknown: 10]
11-May-2007
[1266x3]
hehe
Is there an Agenda for today?
an Agenda for the remote user...