[Developers] Suggestion: New API CCTK_Announce

Tom Goodale goodale at cct.lsu.edu
Fri Jun 3 10:59:20 CDT 2005


Hi,

On Fri, 3 Jun 2005, Jian Tao wrote:

>> Erik proposed a new API
>>>
>>> 	CCTK_Announce ("keyword", "value")
>>>
>>
>> We might also add a "how important is this?" integer argument, perhaps
>> with semantics similar to those of the similar argument to CCTK_VWarn().
>> This would help distinguish important announcements from less important
>> stuff...
>
> Yes, the problem could be solved by introducing "levels" for CCTK_INFO.
>
> We can set the default INFO level to be zero and users can implement their
> own routines to take care of other levels of INFO by using callback mechanism.

This is all sounding very suspiciously like the CCTK_Log (or Syslog) 
functionality which was a planned 4.1 feature;  e.g.

int CCTK_Log(int level, const char *tag, const char *message)

or something like that, taking into account Erik's suggestion for an 
announce API.  Level would be something like the levels we have for Warn 
at the moment, plus an INFO, and maybe more;  e.g. syslog(3) has

        LOG_EMERG
               system is unusable

        LOG_ALERT
               action must be taken immediately

        LOG_CRIT
               critical conditions

        LOG_ERR
               error conditions

        LOG_WARNING
               warning conditions

        LOG_NOTICE
               normal, but significant, condition

        LOG_INFO
               informational message

        LOG_DEBUG
               debug-level message

I don't know if we want to have a significance argument as well to say how 
significant an informational or debug message is - I suspect that is 
probably just duplicating functionality which should properly be in the 
level.

Callbacks should receive all the above arguments, plus thorn name, and 
perhaps a flag to say if something has come from the flesh or a thorn 
(although that is determinable from the 'thorn' argument as it is done at 
the moment).

I had thought to have parameters which could be used to choose which 
things go where, sort of like a /etc/syslog.conf does.

If someone would like to take these ideas, propose a concrete API for the 
Log function and the callbacks, and semantics, and write a thorn, that 
would be great.  ( Obviously if it is in a thorn it wouldn't be CCTK_Log 
8-)

The thorn itself could have some parameters which select events based upon 
some matching criteria and dumps data to a set of files, or this could 
(and probably should) be done in a separate thorn as an example of using 
the callbacks (even if it is in the same thorn it should of course use the 
callbacks).

Cheers,

Tom



More information about the Developers mailing list