On Wed, Dec 2, 2009 at 7:42 AM, sturlamolden wrote:
> On 2 Des, 02:47, Patrick Stinson
> wrote:
>
>> We don't need extension modules, and all we need to do is run some
>> fairly basic scripts that make callbacks and use some sip-wrapped
>> types.
>
> Sure, you use SIP but not extension modules...
On 2 Des, 02:47, Patrick Stinson
wrote:
> We don't need extension modules, and all we need to do is run some
> fairly basic scripts that make callbacks and use some sip-wrapped
> types.
Sure, you use SIP but not extension modules...
> - Python is not suitable for real-time work.
>
> Not true.
Patrick Stinson wrote:
> Not true. We sell the industry leading sampler engine, and it has been
> paying my salary for three years. It's high performance - every cycle
> counts. Our sampled instruments is loaded as a plugin from third-party
> applications and has been used to make movies you have
yes, using an rpc mechanism would insert a "blocking" call into a
thread in which I am "not allowed to make a blocking call," but actual
turn around times would be far better than forcing all threads to wait
on the Gil. As it stands, blocking on a single thread lock *almost*
works, and while we can
In article <4b0b07a1$0$22159$9b622...@news.freenet.de>,
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote:
>
>In any case, I don't think you'll need a multi-process solution; a
>single-process multi-threading approach will do fine. Just create
>*another* thread, that runs at a low priority and is
Le Tue, 24 Nov 2009 09:27:24 -0800, sturlamolden a écrit :
>
> Windows does not have daemons, so this is obviously incorrect. (There
> are something called Windows Services, but multiprocessing does not use
> them.)
This is nitpicking. Technically it might not be a daemon but it's used as
such.
On 24 Nov, 16:13, Antoine Pitrou wrote:
> >> Has anyone every tried wrapping the CPython lib into a daemon with an
> >> RPC mechanism in order to move the GIL out of the process?
>
> >> I imagine this is how the multiprocessing module works.
>
> > It does not.
>
> Actually, it is how multiprocess
Le Tue, 24 Nov 2009 02:53:30 -0800, sturlamolden a écrit :
> On 22 Nov, 22:38, Patrick Stinson
> wrote:
>
>> Has anyone every tried wrapping the CPython lib into a daemon with an
>> RPC mechanism in order to move the GIL out of the process?
>
>> I imagine this is how the multiprocessing module w
On Nov 24, 2009, at 5:58 , sturlamolden wrote:
I have programmed parallel numerical software in Python, including on-
line signal processing. I have yet to find the GIL gets in my way.
Usually people complaining about the GIL does not know what they are
talking about.
I'd love to know which
On 24 Nov, 12:15, Daniel Fetchinson wrote:
> By the way, you might be interested in this thread as well:
>
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/...
It is Windows specific, and it does not work with extension modules.
Yes we can embed multiple interpreters just
>> icating) the multiprocessing module would be ideal.
>>> > The problem is that the OP has a embedded application running threads.
>>> > multiprocssing doesn't help there.
>>>
>>> that's right. I cannot make CPython calls from my original C-based
>>> threads.
>>
>>
>> It's quite possible to do tha
On 23 Nov, 22:02, Patrick Stinson
wrote:
> What I meant was that I am *not allowed* to make calls to the CPython
> API from the threads I currently have because these threads are high
> priority and are never allowed to make blocking calls. Fortunately,
> each of these threads can have a complete
On 22 Nov, 22:38, Patrick Stinson
wrote:
> Has anyone every tried wrapping the CPython lib into a daemon with an
> RPC mechanism in order to move the GIL out of the process?
> I imagine this is how the multiprocessing module works.
It does not.
--
http://mail.python.org/mailman/listinfo/pyth
> What I meant was that I am *not allowed* to make calls to the CPython
> API from the threads I currently have because these threads are high
> priority and are never allowed to make blocking calls. Fortunately,
> each of these threads can have a completely separate interpreter, so
> my idea was t
Patrick Stinson schrieb:
On Mon, Nov 23, 2009 at 1:01 AM, Carl Banks wrote:
On Nov 22, 10:58 pm, Patrick Stinson
wrote:
On Sun, Nov 22, 2009 at 3:15 PM, Diez B. Roggisch wrote:
icating) the multiprocessing module would be ideal.
The problem is that the OP has a embedded application running
On Mon, Nov 23, 2009 at 1:01 AM, Carl Banks wrote:
> On Nov 22, 10:58 pm, Patrick Stinson
> wrote:
>> On Sun, Nov 22, 2009 at 3:15 PM, Diez B. Roggisch
>> wrote:
> icating) the multiprocessing module would be ideal.
>> > The problem is that the OP has a embedded application running threads.
>>
On Nov 22, 10:58 pm, Patrick Stinson
wrote:
> On Sun, Nov 22, 2009 at 3:15 PM, Diez B. Roggisch wrote:
icating) the multiprocessing module would be ideal.
> > The problem is that the OP has a embedded application running threads.
> > multiprocssing doesn't help there.
>
> that's right. I cannot m
that's right. I cannot make CPython calls from my original C-based threads.
On Sun, Nov 22, 2009 at 3:15 PM, Diez B. Roggisch wrote:
> Daniel Fetchinson schrieb:
>>>
>>> Has anyone every tried wrapping the CPython lib into a daemon with an
>>> RPC mechanism in order to move the GIL out of the pro
Daniel Fetchinson schrieb:
Has anyone every tried wrapping the CPython lib into a daemon with an
RPC mechanism in order to move the GIL out of the process? I have
multiple audio threads, each of which use the python interpreter but
don't have to interact with each other and can might as well use
> Has anyone every tried wrapping the CPython lib into a daemon with an
> RPC mechanism in order to move the GIL out of the process? I have
> multiple audio threads, each of which use the python interpreter but
> don't have to interact with each other and can might as well use a
> separate interpre
Has anyone every tried wrapping the CPython lib into a daemon with an
RPC mechanism in order to move the GIL out of the process? I have
multiple audio threads, each of which use the python interpreter but
don't have to interact with each other and can might as well use a
separate interpreter handle
21 matches
Mail list logo
