On Tue, Apr 8, 2008 at 4:46 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > Killing threads at arbitrary points really is that dangerous.
>
> I'm not talking about killing an arbitrary thread, but
> a particular thread that I've designed with the idea of
> killing it in mind.
Adam Olsen wrote:
> Killing threads at arbitrary points really is that dangerous.
I'm not talking about killing an arbitrary thread, but
a particular thread that I've designed with the idea of
killing it in mind.
And I'm not really talking about killing it, either,
just having a way of tapping it
On Mon, Apr 7, 2008 at 11:58 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> We have a way to raise an exception in a thread asynchronously, *but*
> we don't have a way to interrupt either system calls or blocked lock
> acquisitions. I suppose that system calls can be made interruptable
> with
We have a way to raise an exception in a thread asynchronously, *but*
we don't have a way to interrupt either system calls or blocked lock
acquisitions. I suppose that system calls can be made interruptable
with suitable tweaking of various signal-related settings (at least on
Unix -- and I expect
On Mon, Apr 7, 2008 at 7:40 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Maybe it should be a forked subprocess then, if it doesn't touch
> > anything shared?
>
> It might be taking and returning large data structures
> that it would be tedious to transfer between p
On Mon, Apr 7, 2008 at 8:40 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Huh? We do that all the time. We won't let you control when memory is
> > deallocated.
>
> I hardly think that being able to kill threads is
> anywhere near as dangerous as being able to scribble
Guido van Rossum wrote:
> Maybe it should be a forked subprocess then, if it doesn't touch
> anything shared?
It might be taking and returning large data structures
that it would be tedious to transfer between processes.
Pickling them might not be straightforward if they
contain references to obj
[catching up on old threads]
On Tue, Mar 18, 2008 at 5:47 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > I'd tend to assume only *purely* functional languages should have
> > asynchronous interrupts. Any imperative language with them is
> > suspect.
>
> Yet there are situat
FWIW, I think thread interruption/cancellation deserves a PEP. There
are a bunch of subtle issues like this, several other languages that
we can imitate, and a lot of places in the implementation that will
need to change to support it. I was planning to write the PEP a month
or two from now, but if
On Tue, Mar 18, 2008 at 6:47 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > I'd tend to assume only *purely* functional languages should have
> > asynchronous interrupts. Any imperative language with them is
> > suspect.
>
> Yet there are situations where *not* having any su
Adam Olsen wrote:
> I'd tend to assume only *purely* functional languages should have
> asynchronous interrupts. Any imperative language with them is
> suspect.
Yet there are situations where *not* having any such thing
can be extremely inconvenient.
If I'm performing some background calculation
On Tue, Mar 18, 2008 at 4:52 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:
>
>
> > Search for info on java's deprecated Thread.stop() if you're not
> > already familiar with the problems it has.
>
> The problem with Java'
Dnia 18-03-2008, Wt o godzinie 16:22 -0600, Adam Olsen pisze:
> Search for info on java's deprecated Thread.stop() if you're not
> already familiar with the problems it has.
The problem with Java's Thread.stop() is that it is not possible to
block it in a given region, and that it is not possible
On Tue, Mar 18, 2008 at 4:04 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 14:32 -0600, Adam Olsen pisze:
>
>
> > The finalizer thread blocks until something's been deleted.
>
> Ok. If this is the only use case, I feel quite safe not having this,
> bec
Dnia 18-03-2008, Wt o godzinie 14:32 -0600, Adam Olsen pisze:
> The finalizer thread blocks until something's been deleted.
Ok. If this is the only use case, I feel quite safe not having this,
because my finalizers are implemented independently (and a finalizer
thread is created on demand, which
On Tue, Mar 18, 2008 at 2:04 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 13:37 -0600, Adam Olsen pisze:
>
>
> > What sort of blocking wait do you use? Or did you mean you don't have one?
>
> I meant that I don't have one, I only have iteration over t
Dnia 18-03-2008, Wt o godzinie 13:37 -0600, Adam Olsen pisze:
> What sort of blocking wait do you use? Or did you mean you don't have one?
I meant that I don't have one, I only have iteration over the whole
queue, which is equivalent to having trypop. Which prompts the question:
what are use cas
On Tue, Mar 18, 2008 at 1:13 PM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 18-03-2008, Wt o godzinie 11:24 -0600, Adam Olsen pisze:
>
>
> > If they need access to containing objects the only option is to use
> > the underlying tool, deathqueues.
>
> Deathqueues are a part of py
Dnia 18-03-2008, Wt o godzinie 11:24 -0600, Adam Olsen pisze:
> If they need access to containing objects the only option is to use
> the underlying tool, deathqueues.
Deathqueues are a part of python-safethread, right?
Interesting, but just like the finalization design, the design with
weakrefs
On Tue, Mar 18, 2008 at 10:15 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Adam Olsen schrieb:
>
>
> > On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
> > <[EMAIL PROTECTED]> wrote:
> >> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
> >> <[EMAIL PROTECTED]> wrote:
> >> > Dnia 1
Adam Olsen schrieb:
> On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
> <[EMAIL PROTECTED]> wrote:
>> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
>> <[EMAIL PROTECTED]> wrote:
>> > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>> >
>> > > I've replaced __del__ AP
On Tue, Mar 18, 2008 at 9:21 AM, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
> <[EMAIL PROTECTED]> wrote:
> > Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
> >
> > > I've replaced __del__ API (which resurrected objects)
On Tue, Mar 18, 2008 at 6:39 AM, Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> wrote:
> Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
>
> > I've replaced __del__ API (which resurrected objects) with a
> > __finalize__/__finalizeattrs__ API (which doesn't). Attributes listed
> >
Dnia 17-03-2008, Pn o godzinie 11:56 -0600, Adam Olsen pisze:
> I've replaced __del__ API (which resurrected objects) with a
> __finalize__/__finalizeattrs__ API (which doesn't). Attributes listed
> in __finalizeattrs__ are proxied into a core object, a finalizer
> thread is given a reference to
On Mon, Mar 17, 2008 at 1:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 12:56 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Guido's asked me to give a quick status report, so here I go..
> >
> > The critical parts of the design and implementation are basically
>
Thanks! Would you care to give us a hint on how a typical
multi-threaded application would be written using this approach? How
much pre-existing code would break do you expect?
On Mon, Mar 17, 2008 at 12:56 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Guido's asked me to give a quick status report,
26 matches
Mail list logo
