World: r3wp
[DevCon2007] DevCon 2007
older newer | first last |
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... | |
older newer | first last |