title: zerolog prevents go runtime from "deadlocking" on my machine
body: <p>I've stumbled upon a very peculiar case. Apparently <a href="https://github.com/rs/zerolog" rel="nofollow noreferrer">https://github.com/rs/zerolog</a> prevents my program from &quot;deadlocking&quot;.</p>
  <p>This is an example of the program:</p>
  <pre><code>package main
  
  import (
      &quot;fmt&quot;
  
      _ &quot;github.com/rs/zerolog/log&quot;
  )
  
  func main() {
      ch := make(chan int)
      fmt.Println(&lt;-ch)
  }
  </code></pre>
  <p>When I run this on my laptop (go version go1.16.10 linux/amd64) the program just doesn't end. When I try to run it on go playground it does hit deadlock after a few seconds though, I'm not sure why: <a href="https://go.dev/play/p/6rkw0jed-6z" rel="nofollow noreferrer">https://go.dev/play/p/6rkw0jed-6z</a></p>
  <p>My zerolog version is v1.26.0</p>
  <p>I suspect some side effect inside zerolog library causes this behavior, but can't figure out which, and can't figure out how to circumvent it... The problem is - it's making my program unsafe to use (I'm writing a piece of code which utilizes channels a lot, and not having this &quot;safe check&quot; is extremely dangerous).</p>
  <p><strong>EDIT</strong>:</p>
  <p>As correctly pointed out in the comments, it does seem that zerolog opens another goroutine which is not blocking.</p>
  <p>Basically it means that I can not rely on the &quot;checkdead&quot; functionality of the runtime, since I don't know which package might have that side effect (spawning goroutines).</p>
  <p>What is the safe and correct way from the receiver's standpoint to end the program if it's impossible that data will be sent into the channel?</p>
  <p>I think the obvious answer is timeout but I don't know how much time it can take for the data to appear - but maybe that's the only way?</p>
  <p><strong>EDIT #2</strong></p>
  <p>To clarify my question and motive. So far the comments have all been in a tone that I'm asking something silly (that can not be solved - or even considered to be solved). To clarify: I'm not asking &quot;how not write code that deadlocks&quot;. Golang has a built-in &quot;check&quot; that checks if code is stuck: <a href="https://go.googlesource.com/go/+/refs/tags/go1.16.10/src/runtime/proc.go#5038" rel="nofollow noreferrer">https://go.googlesource.com/go/+/refs/tags/go1.16.10/src/runtime/proc.go#5038</a>. So clearly there was an attempt to a general purpose solution from the very language developers.</p>
  <p>Obviously as practice shows, this check can be &quot;broken&quot;. In this case by a package side effect (then again why would zerolog spawn any goroutines during the <code>init</code> phase is beyond my understanding). <strong>So I'm asking is there another way to come up with a general solution that could potentially account for those additional factors.</strong></p>
  <p>If you think there can not be such solution, well it may be true, but maybe someone has an idea.</p>
  <p><strong>EDIT #3</strong></p>
  <p>After further comments from @JimB it seems that it is indeed a problem that can not be fix with a general solution, because of no ability to have knowledge of other running goroutines and blocking conditions.</p>
  <p>So the strategy to detect &quot;deadlocks&quot; in the program should be unique to every possible &quot;blocking&quot; operation it has.</p>
  <p>I'll leave this open just for the informational purpose.</p>