Yes, a hang in one goroutine will spread to the rest of the goroutines,
because the loop in engine() is run while holding the lock on the map. If
it hangs in Write(), any other goroutine trying to run engine() would block
on m.Lock().
By the way, in main() you might as well just say server() instead of go
server(); select{}. server() already never returns so main will never exit
in either case.
On Tue, Jan 24, 2017 at 4:38 PM <andrewinfo...@gmail.com> wrote:
>
> I am writing a program that is similar to a chat server.
>
> There is one server goroutine and a new goroutine is created for each
> client that connects. I find channels a bit difficult to reason about, so
> I am simply using a mutex where appropriate inside each package.
>
> An extremely simplified version of the program is here:
> https://play.golang.org/p/wM9Wiv9QXG (won't run in the playground because
> it binds to a port).
>
> My question is: From reading the documentation it is not clear to me under
> what circumstance a goroutine yields to another goroutine. With this
> design, can a problem in one goroutine cause the program as a whole to
> hang? In other words: will the other users continue to be able to have an
> interactive experience if the connection to one user's machine becomes
> non-responsive, hangs, etc.
>
> Thanks in advance.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
