Re: locking in hidraw

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

 



Am Montag, 1. Dezember 2008 11:07:13 schrieb Jiri Kosina:
> On Wed, 12 Nov 2008, Oliver Neukum wrote:
> 
> > > > > in this code:
> > > > > 
> > > > > 		mutex_lock(&list->read_mutex);
> > > > > 
> > > > > 		if (list->head == list->tail) {
> > > > > 			add_wait_queue(&list->hidraw->wait, &wait);
> > > > > 			set_current_state(TASK_INTERRUPTIBLE);
> > > > > it would make more sense to lock the mutex interruptable so all
> > > > > tasks sleep the same way. Is this intentional?
> > > Well, we have the test for pending signals just below that code, right?
> > So the tasks blocking on the mutex sleep all the time until another
> > task is finished and unlocks the mutex, only to return to user space
> > because signals are pending. Therefore why not make the wait on
> > the mutex interruptible, so the signals are processed right away?
> 
> Yes, it makes sense. Could you please fold this change together with the 
> hidraw changes you are going to push with the autosuspend patches?

On second thought, no, this would not be a good idea. Bug fixes, fixes
for oddities such as this and clear enhancements, like autosuspend, should
be kept apart. I'd rather send separate patches for this, what do you think?

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

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux