... and I have a feeling that this will probably also fix the bad-assumptions that I had on the close_extra_socks(), if I only fork on mod_child_init() and not later.<br><br>Cheers,<br>-Dragos<br><br><div class="gmail_quote">
On Wed, Jul 29, 2009 at 2:58 PM, Dragos Vingarzan <span dir="ltr"><<a href="mailto:dragos.vingarzan@gmail.com">dragos.vingarzan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I see... so it seems quite complicated to add all the required locks and to redesign the process_no and my_pid() for not much of a benefit. I did not see this before.<br>
<br>
Well, if this is final and the conclusion is that the restrictions should be in place there on dynamically forked processes, then I'll start redesigning my module. It's a not a huge deal, but now the code is much clear, easier to manage and also potentially faster if each Diameter TCP connection has it's own process. But this is not a must and one universal acceptor/receiver forked at the beginning could do all the ops, much like the TCP structure from ser, right? Where there any performance issues due to some bottlenecks or something like that?<br>
<br>
(I'll probably still keep also my original design too for when you use this CDiameterPeer standalone, outside of ser...)<br>
<br>
Cheers,<br><font color="#888888">
-Dragos</font><div><div></div><div class="h5"><br>
<br>
<br>
Andrei Pelinescu-Onciul wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Jul 23, 2009 at 19:59, Dragos Vingarzan <<a href="mailto:dragos.vingarzan@gmail.com" target="_blank">dragos.vingarzan@gmail.com</a>> wrote:<br>
[...]<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- sip-router_pt.diff<br>
- added a drop_my_process() function - in the cdp module (Diameter) we do have dynamic processes, which fork and exit distinctly from the ser ones, so we need this to clean-up. Without it, such usages would not be possible as the process table would fill and then new forks would be denied<br>
<br>
</blockquote>
<br>
That's very problematic. It breaks process_no, my_pid() and the<br>
assumption that the process number does not change.<br>
These assumptions are used when doing statistics (e.g. tm): a shared<br>
mem array is created with one "entry" for each process. Each process<br>
updates its own entry (e.g. tm_stats[process_no].s.t_created++ )<br>
without needing any locking or atomic op (which scale very badly on<br>
multi-cpus due to cacheline ping-pongs).<br>
The same assumptions are used in the shm malloc ng (only testing<br>
prototypes for now in ll_malloc) and might be used in the future for<br>
implementing a RCU like mechanism.<br>
<br>
<br>
Andrei<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Best Regards,<br>Dragos Vingarzan<br>