Le Sun, 08 Nov 2009 21:04:06 -0800, John Nagle a écrit :
> Antoine Pitrou wrote:
>> John Nagle animats.com> writes:
>>> I'd argue against general thread cancellation. Inter-thread
>>> signals, though, have safety problems no worse than the first-thread
>>> only signals we have now. You're al
Antoine Pitrou wrote:
John Nagle animats.com> writes:
I'd argue against general thread cancellation. Inter-thread
signals, though, have safety problems no worse than the first-thread
only signals we have now. You're allowed to raise an exception
in a signal handler, which is effectively t
On Nov 8, 2:50 pm, exar...@twistedmatrix.com wrote:
> I'm curious how this visualization works, since earlier you said
> something to the affect that there were no shared resources. If you
> kill a thread and it had opened a window and was drawing on it, with
> most toolkits, you'll end up with a
John Nagle animats.com> writes:
>
> I'd argue against general thread cancellation. Inter-thread
> signals, though, have safety problems no worse than the first-thread
> only signals we have now. You're allowed to raise an exception
> in a signal handler, which is effectively thread cancella
Antoine Pitrou wrote:
Le Sun, 08 Nov 2009 04:40:26 -0800, sven a écrit :
I really don't get that. If the reason would be that it is too much
work to
implement, then I could accept it.
It would probably be a lot of work and even then it would still be unsafe.
Read for example:
http://msdn.mic
Le Sun, 08 Nov 2009 04:40:26 -0800, sven a écrit :
>
> I really don't get that. If the reason would be that it is too much
> work to
> implement, then I could accept it.
It would probably be a lot of work and even then it would still be unsafe.
Read for example:
http://msdn.microsoft.com/en-us/
On 12:40 pm, s...@uni-hd.de wrote:
On Nov 8, 4:27�am, Carl Banks wrote:
It doesn't sound like the thread is communicating with the process
much. �Therefore:
There is quite a bit of communication -- the computation results are
visulized while they are generated.
I'm curious how this visualiz
On Nov 8, 4:27 am, Carl Banks wrote:
> It doesn't sound like the thread is communicating with the process
> much. Therefore:
There is quite a bit of communication -- the computation results are
visulized while they are generated.
> 1. Run the C code in a separate process, or
> 2. Create the thr
Carl Banks wrote:
Arguing that there are good reasons to allow killing threads isn't
going to get you very far. The language developers already know
killing a thread is useful, yet the disallowed it anyway. The
drawbacks were judged too severe (it makes enforcing invariants pretty
much impossib
On Nov 7, 6:04 pm, Sven Marnach wrote:
> So do I really have to refactor my C library just because Python
> Thread objects lack a cancel method? Is there really no other way?
It doesn't sound like the thread is communicating with the process
much. Therefore:
1. Run the C code in a separate pro
Hi,
the Python threading module does not seem to provide a means to cancel
a running thread. There are many discussions on the web dealing with
this issue and many solutions are offered, but none of them seems to
be applicable to my situation, which is as follows:
I have a C library which does s
11 matches
Mail list logo
