2008/12/17 Greg Ewing :
> Nick Coghlan wrote:
>
>> Actually, I believe 3.0 already took a big step towards allowing this by
>> changing the way modules are initialised.
>
> It's a step, but I wouldn't call it a big one. There are
> many other problems to be solved before fully independent
> interpr
On Wed, Dec 17, 2008 at 1:05 PM, Guido van Rossum wrote:
> The inheritance from io.RawIOBase seems fine.
There is a small problem with the interaction between HTTPResponse and
RawIOBase, but I think the problem is more on the http side. You may
recall that the HTTP code has a habit of closing th
It sounds like the self-closing is an implementation detail, meant to
make sure the socket is closed as early as possible (which I suppose
is a good thing if there's a server waiting for the final ACK on the
other side). Perhaps it should not use close() but something slightly
lower level that affe
Jeremy Hylton wrote:
> but I worry that change the self-closing
> behavior too dramatically isn't appropriate for a bug fix. Will look
> some more at this tomorrow.
Reading through the code, it looks like you've already fixed bug 1348.
Thanks!
Bill
On Thu, Dec 18, 2008 at 12:27 PM, Guido van Rossum wrote:
> It sounds like the self-closing is an implementation detail, meant to
> make sure the socket is closed as early as possible (which I suppose
> is a good thing if there's a server waiting for the final ACK on the
> other side). Perhaps it
Paul Moore wrote:
Do you know if these remaining problems are listed anywhere?
There was a big discussion about this in comp.lang.python
not long ago. Basically all the built-in types and constants
are shared between interpreters, which means you still need
a GIL to stop different interpreters
Greg Ewing wrote:
> Paul Moore wrote:
>> Do you know if these remaining problems are listed anywhere?
>
> There was a big discussion about this in comp.lang.python
> not long ago. Basically all the built-in types and constants
> are shared between interpreters, which means you still need
> a GIL t
2008/12/18 Greg Ewing :
> Paul Moore wrote:
>>
>> Do you know if these remaining problems are listed anywhere?
>
> There was a big discussion about this in comp.lang.python
> not long ago. Basically all the built-in types and constants
> are shared between interpreters, which means you still need
>
Paul Moore schrieb:
> OK, but how close is it to providing isolation for threads running
> under the control of the GIL? I'm thinking of something along the
> lines of an in-process version of fork(), which spawns a new
> interpreter and runs the 2 interpreters as threads, still using the
> GIL to
> OK, but how close is it to providing isolation for threads running
> under the control of the GIL?
They won't be indedepent. If an extension module has a global variable,
that will be shared across interpreters. If that variable supports
modifiable state, such modifications will "leak" across i
10 matches
Mail list logo
