[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freediameter-help
Subject:    [Help] Generic questions
From:       sdecugis () freediameter ! net (Sebastien Decugis)
Date:       2012-03-15 11:24:02
Message-ID: 4F61D152.1040102 () freediameter ! net
[Download RAW message or body]

If your change is:
- conservative (i.e. if not interested in the new feature, other people 
do not have to change their code)
- useful (this can be used by other people than you)
- and under the same license as freeDiameter,

then I will be happy to include in the base code line :)

If possible, you can also register your callback to catch all debug 
information, i.e. it is sent to your hook instead of the default stdout 
mechanism. That would be useful in some circumstances.

Looking forward to your patch :)

Sebastien.


Le 2012/03/15 11:43, zack Hasit a ?crit :
> Just to clarify on my email below, suggesting a call back method that
> can be defined in extension and every time a trace/error is logged
> from base stack this call back also gets called (before or after the
> trace is written). That way your current tracing remains intact and
> anyone can do anything additional if needed for Error messages.
> 
> On Thu, Mar 15, 2012 at 3:38 PM, zack Hasit<zackhasit at gmail.com>  wrote:
> > > > You can certainly redefine functions and macro as you like, that's the whole \
> > > > point of having an open-source project :-)
> > 3. I was hoping that I would not have to modify the base stack code
> > ever since that would require us to maintain it separately and update
> > for every new release that is out. I understand the concept of open
> > source but I am hoping that you can consider this change for benefit
> > of everybody using it. Would you consider inclusion if I did the
> > change ?
> > 
> > On Thu, Mar 15, 2012 at 2:49 PM, Sebastien Decugis
> > <sdecugis at freediameter.net>  wrote:
> > > > 1. Since I initialize fdcore as a separate thread (not main thread as
> > > > in your sample daemon) in my process I guess I would just need to
> > > > check on that fdcoe initialization thread to see if it terminates and
> > > > terminate the process myself. Correct ? This should make sure that
> > > > process terminates if there is problem with any thread. If true, this
> > > > would work just fine.
> > > 
> > > Yes. The freeDiameterd daemon example shows how to interact with the
> > > freediameter core: starting it, waiting for it to terminate (it terminates
> > > only on error or request), request termination, ... You can perfectly do
> > > that in a thread. If your thread calls fd_core_wait_shutdown_complete() then
> > > returns, you just have to pthread_join this thread to detect the
> > > termination.
> > > 
> > > 
> > > 
> > > > 2. Well so you do not think there should be error handling because
> > > > there should't be any error :o).
> > > No, I mean that for recoverable errors the recovery should already be
> > > implemented (unless I missed some cases). So, the errors that remain are
> > > situations that cannot be recovered. Note that in several places in the code
> > > if such situation is detected, there is an assert().
> > > 
> > > 
> > > > I think all network components have
> > > > this type of mechanism built in anyhow for continuous
> > > > availability/monitoring. Sometimes bugs get in and they don't get
> > > > identified until in production which is very very costly. Is it a lot
> > > > of work for this change ?
> > > I understand the rationale. Still, I don't see where deadlocks can happen in
> > > the code. Because this framework is multi-threaded and not based on an event
> > > pump, it is difficult to implement a monitoring as you describe, because one
> > > thread may be stuck but all other threads continuing normally. The only
> > > situation that is worth the check in my opinion is if a thread terminates
> > > unexpectedly and it does not trigger a cascaded reaction in the framework;
> > > this might happen under unfrequent error cases that I never met before.
> > > 
> > > 
> > > > 3. So can you allow stack code to also follow new methods/defines ? I
> > > > am mostly interested in ERRORs/Warning so that they can be consistent
> > > > in the whole systems for monitoring reasons. Do you think it is
> > > > reasonable ?
> > > 
> > > You can certainly redefine functions and macro as you like, that's the whole
> > > point of having an open-source project :-)
> > > 
> > > Best regards,
> > > Sebastien.


[prev in list] [next in list] [prev in thread] [next in thread]