On Thursday, June 27, 2019, 03:40:56 PM PDT, Yonatan Zunger
wrote:
> One possible approach (at a very schematic level, not thinking about impl
> details yet) would be to have a function like Thread.raise(e: BaseException)
> which stuffs the exception into thread-local storage, which then
Although thinking about it more, and in the context of this thread, the
idea of an operation to "raise exception X in thread Y" doesn't seem
unreasonable. After all, this is basically what happens to the main thread
from the signal handler already; the C signal handler caches a bit that
gets picked
On Jun 27, 2019, at 13:36, Michael Foord wrote:
>
>> On Thu, 27 Jun 2019 at 20:53, Yonatan Zunger wrote:
>> Generally, threads don't have a notion of non-cooperative thread
>> termination.
> That's precisely why thread cancellation in managed languages (like Python
> is) raise an exception t
Sorry for the rude tone of part of that email.
Sent from my iPhone
> On 27 Jun 2019, at 23:36, Michael Foord wrote:
>
>
>
>> On Thu, 27 Jun 2019 at 20:53, Yonatan Zunger wrote:
>> Generally, threads don't have a notion of non-cooperative thread
>> termination. This is because (unlike proces
On Thu, Jun 27, 2019 at 1:36 PM Michael Foord wrote:
>
> On Thu, 27 Jun 2019 at 20:53, Yonatan Zunger wrote:
>
>> Generally, threads don't have a notion of non-cooperative thread
>> termination. This is because (unlike processes) threads share address
>> spaces, and an unexpected termination of
On Thu, 27 Jun 2019 at 20:53, Yonatan Zunger wrote:
> Generally, threads don't have a notion of non-cooperative thread
> termination. This is because (unlike processes) threads share address
> spaces, and an unexpected termination of a thread can leave memory in
> arbitrary and unexpected states.
Generally, threads don't have a notion of non-cooperative thread
termination. This is because (unlike processes) threads share address
spaces, and an unexpected termination of a thread can leave memory in
arbitrary and unexpected states. (For example, what if one thread was
holding a mutex when it
On Thu, 20 Jun 2019 at 16:33, Guido van Rossum wrote:
> On Thu, Jun 20, 2019 at 8:21 AM Michael Foord wrote:
> > It works by raising an exception in the target thread, which the thread
> is free to handle (usually for cleanup and then reraise).
>
> Sure, those are the right semantics. How does i
On Thu, Jun 20, 2019 at 8:21 AM Michael Foord wrote:
> It works by raising an exception in the target thread, which the thread
is free to handle (usually for cleanup and then reraise).
Sure, those are the right semantics. How does it stop blocking I/O though?
Suppose the thread is waiting for a s
On 20/06/2019 16:10, Matúš Valo wrote:
I have found out at least this link:
http://www.voidspace.org.uk/ironpython/threading.shtml
There is also example of aborting thread.
"""
The next sections provide some simple examples of threading with
IronPython, and illustrates using Thread.Abort. Th
On Thu, 20 Jun 2019 at 16:11, Matúš Valo wrote:
> I have found out at least this link:
>
> http://www.voidspace.org.uk/ironpython/threading.shtml
>
> There is also example of aborting thread.
Thanks, good reference 😀
It also mentions the same API in Java.
Michael
>
> Matus
> __
On Thu, 20 Jun 2019 at 13:03, Robert Collins
wrote:
> Do you have a link to that? Googling king .net threads got me some strange
> results 😁.
>
Auto-correct. Killing.
Thread.abort I believe. I don't think it's very hard to find.
> What made it particularly sane?
>
A straightforward API that
I have found out at least this link:
http://www.voidspace.org.uk/ironpython/threading.shtml
There is also example of aborting thread.
Matus
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-le...@pyth
Do you have a link to that? Googling king .net threads got me some strange
results 😁.
What made it particularly sane?
On Thu, 20 Jun 2019, 23:59 Michael Foord, wrote:
>
>
> On Thu, 20 Jun 2019 at 06:15, Matúš Valo wrote:
>
>> Hi All,
>>
>> Currently it is not possible to "kill" thread which is
On Thu, 20 Jun 2019 at 06:15, Matúš Valo wrote:
> Hi All,
>
> Currently it is not possible to "kill" thread which is blocked. The
> rationale for this is handling situations when thread is blocked - e.g.
> when thread is quering DB when lock occurred on Database. In this case, the
> main thread h
Thank you for your reply. The use case is simple just to offload SQL query to
separate thread to not block main thread. The problem is handling situation
when thread is blocked due I/O to Database. I am not aware about solution like
timeout of query etc. but maybe I have missed something.
__
On Jun 19, 2019, at 22:14, Matúš Valo wrote:
>
> Hi All,
>
> Currently it is not possible to "kill" thread which is blocked. The rationale
> for this is handling situations when thread is blocked - e.g. when thread is
> quering DB when lock occurred on Database.
> pthread library and Windows
IME in many of these cases you're better off using asyncio instead.
-- Ryan
https://refi64.com/
On Jun 20, 2019, 12:14 AM -0500, Matúš Valo , wrote:
> Hi All,
>
> Currently it is not possible to "kill" thread which is blocked. The rationale
> for this is handling situations when thread is blocked
18 matches
Mail list logo
