Re: [PATCH v2 2/4] rsockets: retry for completion events upon interruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 17, 2014 at 04:27:05PM +0000, Hefty, Sean wrote:
> > +resume_get_cq_event:
> >   	ret = ibv_get_cq_event(rs->cm_id->recv_cq_channel, &cq, &context);
> >   	if (!ret) {
> >   		ibv_ack_cq_events(rs->cm_id->recv_cq, 1);
> >   		rs->cq_armed = 0;
> > +	} else if (restart_onintr == 1 && errno == EINTR) {
> > +		errno = 0;
> > +		goto resume_get_cq_event;
> 
> I'm not convinced that this is desirable behavior.  If the thread
> waiting for an event was interrupted, why does it make sense to
> ignore the interrupt and return to waiting?  Couldn't the app detect
> the return code and call back into rsockets in this case?

More broadly, it doesn't make sense for a library to check EINTR in
one place without also checking every blocking syscall it makes.

Realistically, apps that want to use signals in this way will need to
see the EINTR at the app level, while apps that don't care should be
using SA_RESTART to prevent EINTR from being generated.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux