Re: GraphicsMagick may collapse when binding into a server

I found a word：

> before calling C code the go runtime will lock the current goroutine on
> the current OS thread.
> in a C function called from Go I can rely on the fact that it will execute
> in the same OS thread regardless of what it does
>


On Tue, May 21, 2013 at 9:54 PM, Bob Friesenhahn <
[email protected]> wrote:

> 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 <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/ <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
> [email protected], http://www.simplesystems.org/**
> users/bfriesen/ <http://www.simplesystems.org/users/bfriesen/>
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>



-- 
冯立元

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk

_______________________________________________
Graphicsmagick-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs