[Dillo-dev]why use "ccc chain" instead of calling the function directly?
Use "ccc chain" mechanism makes the code seeming uniform. But it cause the source code difficult to understand because lots of indirect function call and variety of parameters. I wonder whether we can call the target function directly instead of using "ccc chain", but I do not know if there is difference between these two methods ??? ( such as the process's address space??? )..... --------------------------------- Do You Yahoo!? 惠普TT游戏剧，玩游戏，中大奖！
On Sat, 3 Apr 2004, [gb2312] Lei Jin wrote:
Use "ccc chain" mechanism makes the code seeming uniform. But it cause the source code difficult to understand because lots of indirect function call and variety of parameters.
The other way is to use threads and mutexes (much more complex and a bit slower too).
I wonder whether we can call the target function directly instead of using "ccc chain", but I do not know if there is difference between these two methods ???
The CCC is not just a way of making function calls, is a theory that allows for implementing non-preemptive parallelism without threads or forks. All the networking and error control in Dillo is driven by these pseudo-threads each shaped as a dynamic CCC. There can be even hundreds of them running at the same time (depending on the page, and on how many pages are loading in the background). Each thread doing network jobs can linger for a long time (generally measured in seconds, depending on latency, network load, size of the transfer, bandwidth etc) --that explains the need for a parallel approach--, now, each one of those threads needs independent error control and recovery, and it may have several steps to perform, so it also has to keep track of its state. That's the job of the CCC. It looks like contrived complexity, for sure, but that's mainly because people don't even start to realize that it handles parallelism in a single address space. This is a bit of my fault, I created the theory while working on Dillo, but I've never had the time to write it down and present it in abstract. Priorities always stood in the way. To my relief, it has worked rock solid, flexible enough to even account for plugins, and has needed low maintenance. Beleieve it or not, when things arrive to this state, the Jargon file regards them as "Deep magic". Cheers Jorge.-
Thank you for your detail explanation. I am still confused. Would you provide an example such as the situation of the two threads doing network job(what happens when using threads and mutexes and when using CCC chain)? Maybe it will help to understand. Jorge Arellano Cid <jcid@dillo.org> wrote: On Sat, 3 Apr 2004, [gb2312] Lei Jin wrote:
Use "ccc chain" mechanism makes the code seeming uniform. But it cause the source code difficult to understand because lots of indirect function call and variety of parameters.
The other way is to use threads and mutexes (much more complex and a bit slower too).
I wonder whether we can call the target function directly instead of using "ccc chain", but I do not know if there is difference between these two methods ???
The CCC is not just a way of making function calls, is a theory that allows for implementing non-preemptive parallelism without threads or forks. All the networking and error control in Dillo is driven by these pseudo-threads each shaped as a dynamic CCC. There can be even hundreds of them running at the same time (depending on the page, and on how many pages are loading in the background). Each thread doing network jobs can linger for a long time (generally measured in seconds, depending on latency, network load, size of the transfer, bandwidth etc) --that explains the need for a parallel approach--, now, each one of those threads needs independent error control and recovery, and it may have several steps to perform, so it also has to keep track of its state. That's the job of the CCC. It looks like contrived complexity, for sure, but that's mainly because people don't even start to realize that it handles parallelism in a single address space. This is a bit of my fault, I created the theory while working on Dillo, but I've never had the time to write it down and present it in abstract. Priorities always stood in the way. To my relief, it has worked rock solid, flexible enough to even account for plugins, and has needed low maintenance. Beleieve it or not, when things arrive to this state, the Jargon file regards them as "Deep magic". Cheers Jorge.- _______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev --------------------------------- Do You Yahoo!? 惠普TT游戏剧，玩游戏，中大奖！
On Wed, 7 Apr 2004, [gb2312] Lei Jin wrote:
Thank you for your detail explanation.
ACK. First of all, there's no need to CC me, I read dillo-dev!
I am still confused. Would you provide an example such as the situation of the two threads doing network job(what happens when using threads and mutexes and when using CCC chain)? Maybe it will help to understand.
When using threads and mutexes (pthreads), thread scheduling is done by a third thread or by the kernel (depends upon the implementation), and it is preemptive. Now, the address space may be shared, so the need for mutexes arise, and because of both reasons, performance is degraded. Using a pseudo-thread (CCC thread), doesn't require scheduling by an external process or by the kernel. All is done in the same process, but there's no preemption. (If you ever have heard that unthreaded servers are faster than threaded counterparts, you'll find the same reasons behind.) Now, since CCC-threads are not preemtive, Dillo also makes use of pthreads when it needs this ability (for instance for DNS resolving). As all the CCC-threads run in the same process, it's easy to sync with pthreads with a polling wait and an event. Cheers Jorge.-
participants (2)
-
Jorge Arellano Cid -
Lei Jin