RE: [Log4cpp-devel] AsyncAppender and others

[Bastiaan B. <Bas...@li...>]

> -----Original Message-----
> From: LECLERCQ Nicolas [mailto:nic...@so...]
> Sent: Friday, May 03, 2002 12:04 PM
> To: log...@li...
> Subject: [Log4cpp-devel] AsyncAppender and others
>=20
>=20
> Hi there,
> After a preliminary discussion with Bastiaan, I suggest to=20
> had to following features to log4cpp:
>=20
> 1 - AsyncAppender class.=20
>=20
> The log4j doc says: <The AsyncAppender lets users log events=20
> asynchronously. It uses a bounded buffer to store logging=20
> events. It will collect the events sent to it and then=20
> dispatch them to all the appenders that are attached to it.=20
> You can attach multiple appenders to an AsyncAppender. The=20
> AsyncAppender uses a separate thread to serve the events in=20
> its bounded buffer>.
>=20
> In order to write the AsyncAppender, we first need to=20
> implement an AppenderAttachable class that could be shared=20
> between the Category class and the AsyncAppender class (code=20
> factorization).  All the existing code dedicated to  the=20
> Appenders management (i.e. such as addAppender,=20
> removeAppender, ...) should be encapsulated in the=20
> AppenderAttachable class.
>=20

Yes, good idea. The appender stuff in Category is an ugly mess right =
now, due to object ownership issues. I feel a better way than having the =
ownsAppender data would be to have the Hierarchy always own the =
appenders or do refcounting. Suggestions are welcome.
=20
> Then we need a log4cpp::threading::Thread class. That's not a=20
> big problem but we have to choose an interface compatible=20
> with (potentially) all underlying implementation of threads.=20
> Since the need is basic, only the fundamental features are=20
> required and the Thread class interface could be something like:=20
>=20

Hmm, I don't know whether log4cpp itself needs a complete thread object =
interface. We could make the AsyncAppender a Runnable (i.e. put the main =
loop in a method named run()) and let the app worry about starting it. I =
suggest first writing the AsyncAppender that way and have the apps do =
the thread control.=20
After people have written the right code for several threading libs it's =
easier to see a minimal abstraction. (For example, I suspect we may not =
need join() or yield()).
I wouldn't want to see a large chunk of code for thread abstraction of =
thread abstraction libraries in log4cpp. It's logging library, not a =
thread library after all.

> class Thread  [: private myPreferredThreadingPackage::Thread ] {
>=20
> public :
> =09
>  // Define only 3 levels of priority.
>  enum {
>     THREAD_PRIORITY_LOW =3D 0,
>     THREAD_PRIORITY_NORMAL,=09
>     THREAD_PRIORITY_HIGH,=09
>  } Priority;
>=20
>   Thread (const char* name);
>   Thread (const std::string& name);
>   // Ctors
>=20
>   virtual ~Thread();
>   // Dtors
>=20
>   int start (void);
>   // Start the thread.
>=20
>   virtual void run (void) =3D  0;
>   // Override this method to provide functionality to your thread.
>=20
>   void join (long milli_secs =3D 0);
>   // Wait at most milli_secs for this thread to terminate. If=20
> milli_secs =3D=3D 0 then wait for ever.
>=20
>   void setPriority (int new_prio);
>   // Set the priority of this thread.
>=20
>   int  getPriority (void) const;   =20
>   // Get the priority of this thread.=20
>=20
>   //... anything else? sleep, yield, ...
>=20
> };
> =20
> The last thing we need to implement the AsyncAppender class=20
> is something similar to the log4j BoundedFIFO. The STL queue=20
> is perfectly adapted to implement such a class.
>=20

Yes, this should be straightforward to implement.

>=20
>=20
> 2 - Log4Cpp class.
>=20
> The aim of the Log4Cpp class is to encapsulate the=20
> init/shutdown stuffs.=20
>=20
> class Log4Cpp {
> public:
>     static int init (void);
>     // Initializer. Return -1 on error, 0 otherwise.
>=20
>     static void shutdown (void);
>     // Cleanup everything before quitting.=20
> };
>=20
> Some packages (such as Java Threads for C++) need to be=20
> initialized to work properly. The Log4Cpp::init could be a=20
> good place for that. The Category::shutdown call could also=20
> be moved to  Log4Cpp::shutdown.=20
>=20

Yes, a proper initialization and shutdown method are useful. However we =
should be careful to allow implicit calling of init() through static =
initilializers (I don't know whether this is allowed for JTC),  because =
people may want to put their Category references in static variables. =
E.g.:

static log4cpp::Category =
SomeClass::_log(log4cpp::Category::getInstance("SomeClass"));


> 3 - Logger and Level classes
>=20
> Just to reflect log4j 1.2 changes.

We could simply add these as typedefs of Category and Priority for now?

Regards,

Bastiaan Bakker
LifeLine Networks bv


>=20
> I'm looking forward to your reactions.
>=20
> Nicolas
> SOLEIL project - http://www.soleil.u-psud.fr.
>=20
>=20
> _______________________________________________________________
>=20
> Have big pipes? SourceForge.net is looking for download=20
> mirrors. We supply
> the hardware. You get the recognition. Email Us:=20
> ban...@so...
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel
>=20