withSuspendingContext
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.
Deprecated
Unsafe: the context is held in thread state across suspension, so a coroutine that resumes on another thread - or interleaves with a sibling - can observe the wrong context. Bind the context to the logger with Logger.withContext(ctx), or use withLogContext from logger-coroutines.
Suspending variant of withContext for use in coroutines. Executes block with ctx merged into the current context, then restores the previous context regardless of whether block throws or suspends.
Thread-safety warning (JVM/Android): This implementation uses a ThreadLocal to hold the context. If the coroutine suspends and resumes on a different thread (e.g. with Dispatchers.IO or Dispatchers.Default), the restored context will not be visible on the new thread. Concurrent coroutines that yield and interleave on the same dispatcher can also observe each other's context.
For correct context propagation across suspension points and thread hops, prefer dev.shivathapaa.logger.coroutines.withLogContext from the logger-coroutines module, which uses dev.shivathapaa.logger.coroutines.LogContextElement (a ThreadContextElement on JVM/Android) to install and restore the context automatically on every thread the coroutine resumes on.
This function is safe to use only when:
The coroutine always resumes on the same thread (e.g.
Dispatchers.Main), andNo other coroutines run concurrently on the same dispatcher.
Neither condition can be enforced or detected by this function, and violating either yields a wrong context rather than a missing one - so it is deprecated. Prefer a mechanism that cannot be wrong:
Logger.withContext binds the context to the logger object; correct on every platform and dispatcher.
dev.shivathapaa.logger.coroutines.withLogContext carries it in the coroutine context, and on JVM/Android additionally keeps this holder in sync.
Return
The value returned by block.
Parameters
The context to merge into the current context for the duration of block.
The suspending block of code to execute within the merged context.