In the blog about symbol table, we discuss the context implementation for variables storage and the symbol table due to they are similar. In this blog, I will discuss the remaining parts about the context implementation.
Besides the value storage, context provides the cancel, timeout and deadline features. In this article, we focus on how the sub contexts are notified by the parent one while children context doesn't affect their parents.
Profile is a common concept among programming languages, it helps to access the program status like CPU, memory usage, and so forth. You may assume that only the languages with runtime could profile, but that's totally wrong. Languages without runtime like C, C++ could profile themselves as well by diverse approaches. For example, the compiler could insert some code instructions for profiling, or the profiler could interrupt the program to record its states periodically.
Half done as I don't have enough knowledge about Go runtime management.
This blog analyzes the implementation of Go sync/mutex after briefing the background knowledge in the previous blog Prerequisite of Go Sync Mutex Implementation.
This blog only concerns mutex.go. It introduces the internal logic of mutex and explains why the mutex shouldn't be copied and why the mutex isn't reentrant.
This blog is split from the blog of sync mutex implementation due to its length. For better reading experience and clearer organization, it's reasonable to make these background knowledge a separated article.
This blog introduces the language level instructions/functions such as atomic and synchronization, the runtime spinning, sleeping and awoken. It also briefs the memory barrier and assembly code in golang.
Last week, during on duty, one user reported his program exited silently without any useful information during deployment, the process is aborted with a killed information:
This is an intrigue question as why the program is killed by OOM killer instead of a fatal stack overflow error.