L117: C-core: replace gpr logging with absl logging #425
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Questions:
|
ctiller
reviewed
Apr 17, 2024
Yes. Removing them is the plan.
Not that I know of. However @ctiller may be able to validate that.
No changes are expected to GRPC_TRACE and related functions.
I will get back on this too. |
|
Re: suppressing the Ack that there'll be some grumbling. Re: GRPC_VERBOSITY: I'd propose we introduce some code that if it's set overrides the absl defaults -- but if it's not set we exert no opinion on what absl does. |
This may cause a lot of frustration with our users, i.e. people may perceive it as some real issue and end up spending time trying to figure out how to fix it, then having to add a dependency to ABSL log (and that may be challenging for people with weird build systems). I feel like we need to be user friendly. |
ctiller
changed the title
ctiller
reviewed
Apr 23, 2024
…acing-gpr-logging-with-abseil-logging.md
…replacing-gpr-logging-with-abseil-logging.md
tanvi-jagtap
changed the title
…cpp-replacing-gpr-logging-with-abseil-logging.md
markdroth
changed the title
markdroth
reviewed
May 1, 2024
…core-replace-gpr-logging-with-abseil-logging.md
ctiller
approved these changes
May 14, 2024
copybara-service bot
pushed a commit
to grpc/grpc
that referenced
this pull request
Jun 7, 2024
…g_function (#36833) Deleting multiple instances of gpr_set_log_function . This function will be deleted soon. grpc/proposal#425 Closes #36833 COPYBARA_INTEGRATE_REVIEW=#36833 from tanvi-jagtap:remove_gpr_log_partial_code 17517ef PiperOrigin-RevId: 641268299
copybara-service bot
pushed a commit
to grpc/grpc
that referenced
this pull request
Jun 8, 2024
…g_function (#36844) [Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_set_log_function Adding a warning for users of gpr_set_log_function. This function will be deleted soon. grpc/proposal#425 Other options considered ( and discarded ) 1. Using DFATAL instead of ERROR. Discarded this because we still have one critical unit test to clean up before we delete gpr_set_log_function. This test will fail if we use DFATAL. EXPECT_DFATAL macro is not available to be used. 2. Considered making a new absl log sink , and then that log sink should have a function pointer with the same signature as gpr_log_func. This function pointer can be set from gpr_set_log_function. However if this custom function uses absl from within it, that will cause infinite recursion. Made me drop the idea. Closes #36844 COPYBARA_INTEGRATE_REVIEW=#36844 from tanvi-jagtap:assert_gpr_set_log_function 805de35 PiperOrigin-RevId: 641473969
This was referenced Jun 18, 2024
copybara-service bot
pushed a commit
to grpc/grpc
that referenced
this pull request
Jun 20, 2024
### Problem 1 Context : gpr_log() internally calls gpr_log_message() . gpr_log_message() may either call gpr_default_log() or a user provided logging function. gpr_default_log() uses absl LOG. This is the default. Most users will log this way. For the small percentage of users who have customized the logging function, gpr_log will log to custom this function. Problem : We have converted half the instances of gpr_log to absl LOG(). For users who use the defaults - there will be no issue. For the users who use a customized logging function 1. All the absl LOGs will log to the absl log sink. 2. All the gpr_log statements will log via this user provided function. This is in-consistent behaviour and will cause confusion and difficulty in debugging. Solution: All logs should go to the same sink. So we decided to make gpr_set_log_function a no op in this release. The function will be deleted in the next release. grpc/proposal#425 ### Problem 2 Context : gpr_should_log is used to avoid computing expensive stuff for logging if the log is not going to be visible. Problem : gpr_should_log was referencing the GRPC_VERBOSITY flag and values set by gpr_set_log_verbosity . However, actual logging happens based on the absl settings. This is incorrect. Because if the old settings are not honoured, they should not be checked and no decision in code should be made based on settings which are not going to get used. Solution : Given the above changes in Problem 1, since all custom logging is disabled, all logging from gRPC with honour the absl LOG settings. Hence we modified the gpr_should_log function to refer to absl settings. ### Problem 3 We still have the issue of php using a custom log sink. We will address this in a separate PR. ### Problem 4 Tests related to test/core/end2end/tests/no_logging.cc are broken . These will be fixed in another PR. Closes #36961 COPYBARA_INTEGRATE_REVIEW=#36961 from tanvi-jagtap:fix_gpr_should_log 70c3224 PiperOrigin-RevId: 645096418
tanvi-jagtap
added a commit
to tanvi-jagtap/tjagtap_grpc
that referenced
this pull request
Jun 20, 2024
### Problem 1 Context : gpr_log() internally calls gpr_log_message() . gpr_log_message() may either call gpr_default_log() or a user provided logging function. gpr_default_log() uses absl LOG. This is the default. Most users will log this way. For the small percentage of users who have customized the logging function, gpr_log will log to custom this function. Problem : We have converted half the instances of gpr_log to absl LOG(). For users who use the defaults - there will be no issue. For the users who use a customized logging function 1. All the absl LOGs will log to the absl log sink. 2. All the gpr_log statements will log via this user provided function. This is in-consistent behaviour and will cause confusion and difficulty in debugging. Solution: All logs should go to the same sink. So we decided to make gpr_set_log_function a no op in this release. The function will be deleted in the next release. grpc/proposal#425 ### Problem 2 Context : gpr_should_log is used to avoid computing expensive stuff for logging if the log is not going to be visible. Problem : gpr_should_log was referencing the GRPC_VERBOSITY flag and values set by gpr_set_log_verbosity . However, actual logging happens based on the absl settings. This is incorrect. Because if the old settings are not honoured, they should not be checked and no decision in code should be made based on settings which are not going to get used. Solution : Given the above changes in Problem 1, since all custom logging is disabled, all logging from gRPC with honour the absl LOG settings. Hence we modified the gpr_should_log function to refer to absl settings. ### Problem 3 We still have the issue of php using a custom log sink. We will address this in a separate PR. ### Problem 4 Tests related to test/core/end2end/tests/no_logging.cc are broken . These will be fixed in another PR. Closes grpc#36961 COPYBARA_INTEGRATE_REVIEW=grpc#36961 from tanvi-jagtap:fix_gpr_should_log 70c3224 PiperOrigin-RevId: 645096418
This was referenced Jun 20, 2024
yashykt
pushed a commit
to grpc/grpc
that referenced
this pull request
Jun 20, 2024
Backport #36961 to v1.65.x ### Problem 1 Context : gpr_log() internally calls gpr_log_message() . gpr_log_message() may either call gpr_default_log() or a user provided logging function. gpr_default_log() uses absl LOG. This is the default. Most users will log this way. For the small percentage of users who have customized the logging function, gpr_log will log to custom this function. Problem : We have converted half the instances of gpr_log to absl LOG(). For users who use the defaults - there will be no issue. For the users who use a customized logging function 1. All the absl LOGs will log to the absl log sink. 2. All the gpr_log statements will log via this user provided function. This is in-consistent behaviour and will cause confusion and difficulty in debugging. Solution: All logs should go to the same sink. So we decided to make gpr_set_log_function a no op in this release. The function will be deleted in the next release. grpc/proposal#425 ### Problem 2 Context : gpr_should_log is used to avoid computing expensive stuff for logging if the log is not going to be visible. Problem : gpr_should_log was referencing the GRPC_VERBOSITY flag and values set by gpr_set_log_verbosity . However, actual logging happens based on the absl settings. This is incorrect. Because if the old settings are not honoured, they should not be checked and no decision in code should be made based on settings which are not going to get used. Solution : Given the above changes in Problem 1, since all custom logging is disabled, all logging from gRPC with honour the absl LOG settings. Hence we modified the gpr_should_log function to refer to absl settings. ### Problem 3 We still have the issue of php using a custom log sink. We will address this in a separate PR. ### Problem 4 Tests related to test/core/end2end/tests/no_logging.cc are broken . These will be fixed in another PR. Closes #36961 COPYBARA_INTEGRATE_REVIEW=#36961 from tanvi-jagtap:fix_gpr_should_log 70c3224 PiperOrigin-RevId: 645096418
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.