Messages in this thread | | | Date | Sat, 6 Jun 2015 23:32:40 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API |
| |
On Sat, 6 Jun 2015, Oleg Nesterov wrote:
> Still I personally dislike the new kthread_sigaction() API. I agree, > a couple if signal helpers for kthreads make sense. Say, > > void kthread_do_signal_stop(void) > { > spin_lock_irq(&curtent->sighand->siglock); > if (current->jobctl & JOBCTL_STOP_DEQUEUED) > __set_current_state(TASK_STOPPED); > spin_unlock_irq(¤t->sighand->siglock); > > schedule(); > }
... not to mention the fact that 'STOP' keyword in relation to kthreads has completely different meaning today, which just contributes to overall confusion; but that's an independent story.
> > and probably even "int kthread_signal_deque(void)". > > But personally I do not think kthread_do_signal() makes a lot of sense...
Would it be possible for you to elaborate a little bit more why you think so ... ?
I personally don't see a huge principal difference between "kthread_signal_dequeue() + kthread_do_signal_{stop,...}" vs. generic "kthread_do_signal()" that's just basically completely general and takes care of 'everything necessary'. That being said, my relationship to signal handling code is of course much less intimate compared to yours, so I am really curious what particular objections to that interface have.
Thanks a lot,
-- Jiri Kosina SUSE Labs
| |