Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPEC] Add urAdapterSetLoggingCallback entrypoint #1

Closed

Conversation

fabiomestre
Copy link
Owner

@fabiomestre fabiomestre commented Feb 28, 2024

Temporarily creating the PR on top of a branch on my fork which contains the following unmerged PR (they are dependencies for this change): oneapi-src#1359, oneapi-src#1347, oneapi-src#1345, oneapi-src#1342, oneapi-src#1032

@fabiomestre fabiomestre marked this pull request as draft February 28, 2024 17:31
Comment on lines +191 to +193
- type: $x_log_level_t
name: logLevel
desc: "[in] The log message type"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like the log level should be set once as an argument to urAdapterSetLoggingCallback. This would mirror how it gets set by environment variable i.e. once per process. The main benefit of setting the log level once is to allow the logging framework to avoid paying the overhead of processing log messages which are going to be ignored.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. I added the extra parameter in the latest commit 👍

- "Sets a function callback that will be used by the adapters when logging messages."
- "The callback will be called for every message logged by the adapters specified in `phAdapters`."
- "Sending log messages is optional and adapters are not required to implement this feature for any entrypoint."
- "The application can disable log messages at runtime by setting the environment variable `UR_DISABLE_LOGS`."
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also define what happens when this entry point is called more than once. Do we replace the callback or append it to a list of callbacks?

I think replacing the callback would be simpler to implement. If that turns out to be an issue we can extend it later.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the wording on the description for this case. Also allowed the callback to be nullptr in case the application wants to unset it.

I'm not sure what to do with the environment variable UR_DISABLE_LOGS. With the logger already having its own env_vars, I think that this variable is a bit redundant (if the application wants to ignore all the logs they can just unset the callback). But would like to hear someone else's opinion. It's not hard to implement the env var if we still think it is relevant.

@fabiomestre fabiomestre closed this Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants