Re: [GM-bugs] GraphicsMagick may collapse when binding into a server

[Bob F. <bfr...@si...>]

On Tue, 21 May 2013, Feng Liyuan wrote:

> Hi,
> I'm running my code on Linux(opensuse) with the latest GraphicsMagick.
> 
> My test code is provided as attach.
> 
> It contains a Makefile after you unzip this.
> 
> If you've installed golang, you can run ` make runserver ` to start the test server and then run ` make runpressure ` to do
> the stress test
> In this test, I opened 10 goroutines to request the server concurrently and the server went down.

I will take a look, but it might not be until this weekend.

In the mean time, perhaps you can do some investigation for me.  I am 
not very familiar with the Go language.  In the concurrency section of 
the Tour of Go, I see mention of Goroutines and it describes it as a 
"lightweight thread managed by the Go runtime".  The FAQ at 
"http://golang.org/doc/faq#goroutines" suggests that goroutines are 
not the same as "threads".

GraphicsMagick uses locking mechanisms from POSIX threads (pthreads). 
If goroutines are not compatible with POSIX threads then the locking 
mechanisms used in GraphicsMagick won't work reliably.  When OpenMP is 
enabled, GraphicsMagick also uses OpenMP's locking mechanisms between 
OpenMP worker threads.

I am getting the impression that goroutines use POSIX threads to gain 
concurrent access to OS system calls but that goroutines themselves 
are light-weight threads where there can be many more goroutines 
active than POSIX threads.  If this is the case then this would cause 
a problem.

There is substantial evidence of this in the article at 
"http://lwn.net/Articles/361454/".

It seems that GraphicsMagick semaphores would need to be 
re-implemented for Go so that they will usefully block goroutines and 
not just POSIX threads.  Alternatively, maybe there is some pragma 
which can be used to tell the Go implementation to use a POSIX thread 
per goroutine when invoking GraphicsMagick functions similar to what 
is done with OS calls.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/