Andre Meyer schrieb:
> While I understand the difficulties in removing the GIL and the
> potential negative effect on single-threaded applications I would very
> much encourage discussion to seriously consider removing the GIL (maybe
> optionally) in Py3k. If not, what alternatives would you sugges
On 9/17/06, Ivan Krstić <[EMAIL PROTECTED]> wrote:
> Andre Meyer wrote:
> > As a heavy user of multi-threading in Python and following the current
> > discussions about Python on multi-processor systems on the python-list I
> > wonder what the plans are for improving MP performance in Py3k.
>
> I h
Andre Meyer wrote:
> As a heavy user of multi-threading in Python and following the current
> discussions about Python on multi-processor systems on the python-list I
> wonder what the plans are for improving MP performance in Py3k.
I have four aborted e-mails in my 'Drafts' folder that are askin
"Ross Jekel" <[EMAIL PROTECTED]> wrote:
> I know it is a bit old, but would Python Object Sharing (POSH)
> http://poshmodule.sourceforge.net help you? Also, if you think you like the
> current state-of-the-art threading model, you might not after reading this:
The RPC-like mechanism I describe
On 9/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> > Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > > It would be substantially easier if there were a distributed RPC
> > > mechanism that auto distributed to the "least-working" process in a
> >
I know it is a bit old, but would Python Object Sharing (POSH)
http://poshmodule.sourceforge.net help you? Also, if you think you like the
current state-of-the-art threading model, you might not after reading this:
http://tinyurl.com/qvcbr
This goes to an article on http://www.computer.org wi
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> > It would be substantially easier if there were a distributed RPC
> > mechanism that auto distributed to the "least-working" process in a
> > set
> > of potential working processes on a single machine. [.
Josiah Carlson <[EMAIL PROTECTED]> wrote:
> It would be substantially easier if there were a distributed RPC
> mechanism that auto distributed to the "least-working" process in a
> set
> of potential working processes on a single machine. [...]
I'm not sure I follow you. Would you mind providing
On Sep 17, 2006, at 3:16 PM, Nick Coghlan wrote:
Andre Meyer wrote:
While I understand the difficulties in removing the GIL and the
potential negative effect on single-threaded applications I would
very
much encourage discussion to seriously consider removing the GIL
(maybe
optionally) in
On 9/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Andre Meyer wrote:> While I understand the difficulties in removing the GIL and the> potential negative effect on single-threaded applications I would very> much encourage discussion to seriously consider removing the GIL (maybe
> optionally) in P
"Andre Meyer" <[EMAIL PROTECTED]> wrote:
> Dear Python experts
>
> As a heavy user of multi-threading in Python and following the current
> discussions about Python on multi-processor systems on the python-list I
> wonder what the plans are for improving MP performance in Py3k. MP systems
> becom
Le dimanche 17 septembre 2006 à 23:16 +1000, Nick Coghlan a écrit :
> Brett Cannon's sandboxing work (which aims to provide first-class support for
> multiple interpreters in the same process for security reasons) also seems
> like a potentially fruitful approach to distributing processing to mul
"Andre Meyer" <[EMAIL PROTECTED]> writes:
> While I understand the difficulties in removing the GIL and the
> potential negative effect on single-threaded applications I would
> very much encourage discussion to seriously consider removing the
> GIL (maybe optionally) in Py3k.
I suppose this woul
Andre Meyer wrote:
> While I understand the difficulties in removing the GIL and the
> potential negative effect on single-threaded applications I would very
> much encourage discussion to seriously consider removing the GIL (maybe
> optionally) in Py3k. If not, what alternatives would you sugge
Dear Python expertsAs a heavy user of multi-threading in Python and following the current discussions about Python on multi-processor systems on the python-list I wonder what the plans are for improving MP performance in Py3k. MP systems become more and more common as most modern processors have mu
15 matches
Mail list logo