One of the traps of concurrency is "incomplete work" which occurs when a program terminates before outstanding Goroutines complete. Depending on the program, this may be a serious problem. This post demonstrates the trap and discusses possible solutions.
Goroutine Leaks are a common cause of memory leaks in Go programs. In my previous post, I presented an introduction to Goroutine leaks and provided one example of a common mistake that many Go developers make. Continuing that work, this post presents another scenario on how Goroutines could be leaked.
Goroutine leaks are a common source of memory leaks in concurrent programs. This post defines Goroutine leaks and provides one example of a leak that is easy to miss in production code.
I’m a big fan of tmux and I use it daily. Over time I will open more
and more windows and my workspace starts to get a bit cluttered. Occasionally I
will try to open some file in vim that is already open in another window. I
used to dread playing “find the right window,” especially if I had backgrounded
vim. This happened often enough that I spent the time to make a little tmux
keybinding for finding that window automatically.
InnoDB is a great storage engine for MySQL offering, among other things,
transaction support. One of its drawbacks is the difficulty that you can face
when corruption inevitably hits.
At work we have dealt with corrupt InnoDB tables often enough to make the
procedure fairly routine. Last week I was faced with a situation that had me
pulling my hair out; in fact we almost threw in the towel.
Looking through the PHPExcel library
recently I saw how Mark Baker overrides the magic
__clone method with
comments about ensuring that cloning will perform a deep copy instead of a
shallow one. This is a topic with which I had not had much experience so I did
some research and experimenting to learn what happens when you use
the difference between a shallow copy and a deep copy.