You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Json currently fails to satisfy slog's SendSyncUnwindSafeDrain because of the internal RefCell, necessitating wrapping it in a Mutex to use it as a drain in slog::Logger. This seems redundant, especially when using Json with io::Stdout or io::Stderr which also use mutexes internally and can be shared across threads.
The simplest solution might be to just replace RefCell with Mutex. Uncontended single-thread access of a mutex isn't much more expensive than RefCell, and since slog::Logger requires Send + Sync + UnwindSafe anyway, it seems more than reasonable just to use Mutex. Of course, there is the issue of poisoning; to be backwards-compatible we could either just ignore poisoning or wrap the poison error in io::Error.
However, I would prefer a more general solution that also allows us to avoid using Mutex for internally synchronized writers like Stdout/Stderr. I'm thinking it would look something like this:
pubstructRecordSerializer<'a>{/**/}impl<'a>RecordSerializer<'a>{/// Write out the log record contained in this serializer to `write`.pubfnwrite_to<W:Write>(self,write:W) -> io::Result<()>{/**/}}pubtraitSharedWrite{/// An error type that can wrap `io::Error` along with any locking error this impl may produce.typeError:From<io::Error>;/// Provide `serializer` with a `std::io::Write` impl via its `write_to()` methodfnwith_writer(&self,serializer:RecordSerializer) -> Result<(),Self::Error>;// I initially conceived of a `lock()` method that returned an impl of `io::Write` but it// would have required generic associated types to bind the lifetime to the `&self` param}pubenumMutexWriteError{Io(io::Error),Poisoned,}impl<T>From<PoisonError<T>>forMutexWriteError{/* */}implFrom<io::Error>forMutexWriteError{/* */}impl<W:Write>SharedWriteforMutex<W>{typeError = MutexWriteError;fnwith_writer(&self,serializer:RecordSerializer) -> Result<(),Self::Error>{let writer = self.lock()?;
serializer.write_to(writer).map_err(Into::into)}}implSharedWriteforStdout{typeError = io::Error;fnwith_writer(&self,serializer:RecordSerializer) -> Result<(),Self::Error>{
serializer.write_to(self.lock())}}implSharedWriteforStderr{typeError = io::Error;fnwith_writer(&self,serializer:RecordSerializer) -> Result<(),Self::Error>{
serializer.write_to(self.lock())}}
The main issue is that this would be a breaking change to Json's API if we changed it to take SharedWrite instead of Write; to be backwards-compatible this would have to be introduced along with a new type that pretty much just duplicates Json's API, which isn't great either.
The text was updated successfully, but these errors were encountered:
Json
currently fails to satisfyslog
'sSendSyncUnwindSafeDrain
because of the internalRefCell
, necessitating wrapping it in aMutex
to use it as a drain inslog::Logger
. This seems redundant, especially when usingJson
withio::Stdout
orio::Stderr
which also use mutexes internally and can be shared across threads.The simplest solution might be to just replace
RefCell
withMutex
. Uncontended single-thread access of a mutex isn't much more expensive thanRefCell
, and sinceslog::Logger
requiresSend + Sync + UnwindSafe
anyway, it seems more than reasonable just to useMutex
. Of course, there is the issue of poisoning; to be backwards-compatible we could either just ignore poisoning or wrap the poison error inio::Error
.However, I would prefer a more general solution that also allows us to avoid using
Mutex
for internally synchronized writers likeStdout
/Stderr
. I'm thinking it would look something like this:The main issue is that this would be a breaking change to
Json
's API if we changed it to takeSharedWrite
instead ofWrite
; to be backwards-compatible this would have to be introduced along with a new type that pretty much just duplicatesJson
's API, which isn't great either.The text was updated successfully, but these errors were encountered: