[dpdk-dev] [dpdk-dev, 1/3] rte_interrupts: add rte_eal_intr_exit to shut down IRQ thread

[Matthew Hall]

>From Cunming:
> I'm trying to understand the motivation.
> 
> I don't think you're going to gracefully exit intr thread but leave all 
> other eal threads live. We don't have API to new launch intr thread again.

The doc comment added for rte_eal_intr_exit already explains this. According 
to the doc I wrote, use of the function is limited to shutting everything 
down.

> So I guess your app is using own pthread(none EAL thread), you're trying to 
> safely shutdown the whole application by your signal handler.

No, the app is using DPDK pthreads, and trying to shutdown everything safely 
and cleanly w/ its signal handler, across DPDK and many other services in the 
app.

Unfortunately, right now from my experience it is impossible to get everything to 
cleanly shutdown, one an interrupt thread is activated. Because interrupt 
threads violate violate POSIX semantics:

1) It ignores EINTR and immediately forcibly restarts a poll() syscall. If the 
signal is delivered to the interrupt thread of the process by the kernel, this 
makes the thread uninterruptible to process the signal. Stuck running forever.

2) It does not properly set PTHREAD_CREATE_DETACHED for a background thread. 
So it holds the process open for its infinite loop of poll(). Stuck running 
forever.

3) There is no way to access the thread_id from intr_thread. So then you can't 
call pthread_cancel on it to shut it down. Stuck running forever.

> For this purpose, the device shall close safely(turn off intr) during the 
> time, intr thread still wait but no event will be raised.

In theory yes. In practice no. Because the intr thread violated POSIX rules 
for background processing threads per above.

> In this view, it seems not necessary to have this new. Can you explain more 
> detail for the purpose?

Based on my testing, I disagree. I could not get reliable shutdowns without 
this, or I wouldn't have coded it. (:

Matthew.