Thu Jan 04 14:44:30 HKT 2018
From
/weblog/languages
How go utilizing-multi-core
package main
import "runtime"
func calc()
{
sum := 0;
for i := 0; ; i++ {
sum += i;
}
}
func main()
{
runtime.GOMAXPROCS(4);
go calc();
go calc();
go calc();
go calc();
go calc();
go calc();
go calc();
calc();
}
http://kzk9.net[..]g-multi-core-in-go-programming-language/ A presentation -
http://wh3rd.net/practical-go/ http://talks.golang.org/2012/splash.slide#1 Some good thing about go -
http://abdullin.com[..]3/12/16/studying-go-language-golang.html About memory management and thread -
http://www.infoq.com/interviews/hudson-go-gc Several good tools -
https://medium.com[..]ous-integration-like-a-boss-941a3a9ad0b6 A few practical comments of using go in production -
https://www.commandercoriander.net/blog/2017/12/31/writing-go/
(google search)
(amazon search)
Mon Aug 12 17:31:03 HKT 2013
From
/weblog/languages/c
How to have good C code -
- Be Disciplined About Namespace Management
- Clearly Document Published APIs
- Keep Data Types Abstract
- Use Polymorphism Judiciously
- Prefer Modularisation Over Conditional Compilation
- The Best Way to Modularise a Large C Codebase is Don't Have a Large C Codebase!
http://www.natpryce.com/articles/000799.html
(google search)
(amazon search)
Thu Mar 01 22:25:13 HKT 2012
From
/weblog/languages/c
Problem of malloc, and introduction to some improved version -
http://betathoughts.blogspot.com/2010/02/history-of-malloc.html Personal memo about C++ memory management, from a Java developer, contain some rule of thumb tips -
http://karussell.wordpress.com[..]c-trying-to-understand-memory-mangement/ Tutorial of valgrind -
http://www.thegeekstuff.com/2011/11/valgrind-memcheck/ Disucssion of GC in C++ -
http://herbsutter.com[..]10/25/garbage-collection-synopsis-and-c/ Core dump with few variable declaration removed -
http://techblog.rosedu.org/c-extern-internals.html Tracking memory allocation -
http://jfdube.wordpress.com[..]-management-part-2-allocations-tracking/ We have a process running fine for several years and recently have core dump everytime starting it up. here is the stacktrace:
(gdb) backtrace
#0 0xfe34251c in realfree () from /lib/libc.so.1
#1 0xfe342e28 in cleanfree () from /lib/libc.so.1
#2 0xfe341f5c in _malloc_unlocked () from /lib/libc.so.1
#3 0xfe341e50 in malloc () from /lib/libc.so.1
#4 0xfe38f534 in _findbuf () from /lib/libc.so.1
#5 0xfe384f38 in _doprnt () from /lib/libc.so.1
#6 0xfe3886fc in fprintf () from /lib/libc.so.1
#7 0x164f64 in _ZN7LogBook8WriteLogEPcS0_i (this=
, pType=0x5c00e8 "INFO",
pMsg=0x6b0b14 "main. Database=XXXXXX. Performing Login to XXXX. user=SYSTEM.", nFile=0) at Util.cpp:164
#8 0x164e28 in _ZN7LogBook9PromptLogEPciS0_i (this=, pType=0x5c00e8 "INFO",
nType=3, pMsg=0x0, nFile=0) at Util.cpp:136
#9 0x14a364 in main (argc=3, argv=0xffbef5bc) at XXXX.cpp:385
(gdb)
Eventaully we found out the reason is the class LogBook is singleton, and it reuse few char* buffer internally, without delete and new in between, after adding delete and new for transaction, the process run correctly, as a rule of thumb, singleton is evil for most of the cases.
(google search)
(amazon search)