fork, threads and proper closing

[Tomasz Pajor]

Hello,

Configuration is as follows.

I have a starter process which creates 3 sub processes (forks) and each
of this processes creates a number of threads.
Threads in that processes have semaphore so on KeyboardInterrupt without
sending a sigterm to the subprocess i'm not able to close threads.
Is there any work around? Can I somehow run join for the thread on
keyboard interrupt?

 

[OdarR]

Hello,

Configuration is as follows.

I have a starter process which creates 3 sub processes (forks) and each
of this processes creates a number of threads.
Threads in that processes have semaphore so on KeyboardInterrupt without
sending a sigterm to the subprocess i'm not able to close threads.
Is there any work around? Can I somehow run join for the thread on
keyboard interrupt?

When creating a thread you can add a Queue parameter to communicate
with threads:
http://docs.python.org/library/queue.html
easy and reliable.

give them a "poison pill" in the queue: a recognizable object placed
on the queue that means "when you get this, stop."

better to not rely on keyboard for thread stopping.

Olivier

 

[Tomasz Pajor]

When creating a thread you can add a Queue parameter to communicate
with threads:
http://docs.python.org/library/queue.html
easy and reliable.

give them a "poison pill" in the queue: a recognizable object placed
on the queue that means "when you get this, stop."

can You provide any working example?

better to not rely on keyboard for thread stopping.

i use keyboard interrupt only for debuging purposes

 

[Francesco Bochicchio]

When creating a thread you can add a Queue parameter to communicate
with threads:http://docs.python.org/library/queue.html
easy and reliable.

give them a "poison pill" in the queue: a recognizable object placed
on the queue that means "when you get this, stop."

This is the way I usually go, but it has one important limitation: if
the thread is waiting
for a blocking I/O operation to complete, like reading from a socket
with no data or waiting
for a locked resource (i.e. semaphore) to be unlocked, it will not
service the queue and will
not read the 'quit command' (the poison pill), and therefore will not
quit until the blocking
I/O terminates (and it could be never).

ASAIK, there is no way - in python - to solve this.

Olivier

Ciao

 

[OdarR]

This is the way I usually go, but it has one important limitation: if
the thread is waiting
for a blocking I/O operation to complete, like reading from a socket
with no data or waiting

add a small wait (time.sleep()), and also, I/O function in Python can
often releas the GIL...

for a locked resource (i.e. semaphore) to be unlocked, it will not
service the queue and will
not read the 'quit command' (the poison pill), and therefore will not
quit until the blocking
I/O terminates (and it could be never).

ASAIK, there is no way - in python - to solve this.

no easy way, yes...
but I think I gave a good advice to our friend Tomasz

Olivier

 

[Lawrence D'Oliveiro]

In message <cf35773f-600b-44a0-9a5b-

... if the thread is waiting for a blocking I/O operation to complete,
like reading from a socket with no data or waiting for a locked resource
(i.e. semaphore) to be unlocked, it will not service the queue and will
not read the 'quit command' (the poison pill), and therefore will not
quit until the blocking I/O terminates (and it could be never).

Under Linux systems, threads are little different from processes. In
particular, sending a thread/process a signal will cause any blocking I/O
operation in progress to abort, either with only some bytes read/written, or
if nothing was read/written, with an EINTR error.