... 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.
Cheers, -Dragos On Wed, Jul 29, 2009 at 2:58 PM, Dragos Vingarzan < [email protected]> wrote: > 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. > > 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? > > (I'll probably still keep also my original design too for when you use this > CDiameterPeer standalone, outside of ser...) > > Cheers, > -Dragos > > > > Andrei Pelinescu-Onciul wrote: > >> On Jul 23, 2009 at 19:59, Dragos Vingarzan <[email protected]> >> wrote: >> [...] >> >> >>> - sip-router_pt.diff >>> - 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 >>> >>> >> >> That's very problematic. It breaks process_no, my_pid() and the >> assumption that the process number does not change. >> These assumptions are used when doing statistics (e.g. tm): a shared >> mem array is created with one "entry" for each process. Each process >> updates its own entry (e.g. tm_stats[process_no].s.t_created++ ) >> without needing any locking or atomic op (which scale very badly on >> multi-cpus due to cacheline ping-pongs). >> The same assumptions are used in the shm malloc ng (only testing >> prototypes for now in ll_malloc) and might be used in the future for >> implementing a RCU like mechanism. >> >> >> Andrei >> >> > > -- Best Regards, Dragos Vingarzan
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
