On Sat, Mar 12, 2016 at 07:48:36PM +0100, Ingo Molnar wrote:
>
> * Rich Felker wrote:
>
> > On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote:
> > >
> > > * Linus Torvalds wrote:
> > >
> > > > [...]
> > > >
> > > > Because if that's the case, I wonder if what you really want is not
* Rich Felker wrote:
> On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote:
> >
> > * Linus Torvalds wrote:
> >
> > > [...]
> > >
> > > Because if that's the case, I wonder if what you really want is not
> > > "sticky
> > > signals" as much as "synchronous signals" - ie the ability
On Sat, Mar 12, 2016 at 06:05:09PM +0100, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Fri, Mar 11, 2016 at 11:39 AM, Linus Torvalds
> > wrote:
> > >
> > > "An implementation may also mark other functions not specified in the
> > > standard as cancellation points"
> >
> > .. but t
On Sat, Mar 12, 2016 at 06:00:40PM +0100, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > [...]
> >
> > Because if that's the case, I wonder if what you really want is not "sticky
> > signals" as much as "synchronous signals" - ie the ability to say that a
> > signal
> > shouldn't ever
(Argh: Mail-Followup-To spam your mailer sets up is nasty!)
* Szabolcs Nagy wrote:
> > 4. A calls cancellation point and syscall correctly executes
> > 5. Once A enables cancellation again, the cancellation propagates.
> >
> > So I still see no problem.
>
> i think the sticky signal desig
* Linus Torvalds wrote:
> On Fri, Mar 11, 2016 at 11:39 AM, Linus Torvalds
> wrote:
> >
> > "An implementation may also mark other functions not specified in the
> > standard as cancellation points"
>
> .. but that was from the Linux man-page. The open group has
>
> "An implementation shal
* Linus Torvalds wrote:
> [...]
>
> Because if that's the case, I wonder if what you really want is not "sticky
> signals" as much as "synchronous signals" - ie the ability to say that a
> signal
> shouldn't ever interrupt in random places, but only at well-defined points
> (where a system
On Fri, Mar 11, 2016 at 11:39 AM, Linus Torvalds
wrote:
>
> "An implementation may also mark other functions not specified in the
> standard as cancellation points"
.. but that was from the Linux man-page. The open group has
"An implementation shall not introduce cancellation points into any
On Fri, Mar 11, 2016 at 11:30 AM, Andy Lutomirski wrote:
>
> I think that this would almost work for musl, except that musl would
> still need to be able to tell whether the syscall that eventually gets
> interrupted is a cancellation point, which still may require some
> ability to unwind from th
On Fri, Mar 11, 2016 at 11:27 AM, Linus Torvalds
wrote:
> On Fri, Mar 11, 2016 at 3:39 AM, Szabolcs Nagy wrote:
>>
>> i think the sticky signal design would work, but more
>> complex than what we have and adds some atomic rmw ops
>> into common code paths and not backward compatible.
>>
>> not us
On Fri, Mar 11, 2016 at 3:39 AM, Szabolcs Nagy wrote:
>
> i think the sticky signal design would work, but more
> complex than what we have and adds some atomic rmw ops
> into common code paths and not backward compatible.
>
> not using vsyscalls for cancellation-points sounds easier.
Hmm. Ok, so
* Ingo Molnar [2016-03-11 10:33:47 +0100]:
> * Rich Felker wrote:
>
> > No, it doesn't work. Cancellability of the target thread at the time
> > of the cancellation request (when you would decide whether or not to
> > send the signal) has no relation to cancellability at the time of
> > calling
* Rich Felker wrote:
> No, it doesn't work. Cancellability of the target thread at the time
> of the cancellation request (when you would decide whether or not to
> send the signal) has no relation to cancellability at the time of
> calling the cancellation point. Consider 2 threads A and B and
On Fri, Mar 11, 2016 at 02:39:47AM +0100, Szabolcs Nagy wrote:
> * Rich Felker [2016-03-10 19:48:59 -0500]:
> > On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote:
> > > * Rich Felker [2016-03-10 18:28:20 -0500]:
> > > > On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote:
> >
* Szabolcs Nagy [2016-03-11 02:39:47 +0100]:
> * Rich Felker [2016-03-10 19:48:59 -0500]:
> > On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote:
> > > * Rich Felker [2016-03-10 18:28:20 -0500]:
> > > > On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote:
> > > > >
> > > > >
* Rich Felker [2016-03-10 19:48:59 -0500]:
> On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote:
> > * Rich Felker [2016-03-10 18:28:20 -0500]:
> > > On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote:
> > > >
> > > > The sticky signal is only ever sent when the thread is in
On Thu, Mar 10, 2016 at 4:48 PM, Rich Felker wrote:
> On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote:
>> * Rich Felker [2016-03-10 18:28:20 -0500]:
>> > On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote:
>> > >
>> > > * Rich Felker wrote:
>> > >
>> > > > > So instead of
On Fri, Mar 11, 2016 at 01:18:54AM +0100, Szabolcs Nagy wrote:
> * Rich Felker [2016-03-10 18:28:20 -0500]:
> > On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote:
> > >
> > > * Rich Felker wrote:
> > >
> > > > > So instead of a sticky cancellation flag, we could introduce a sticky
>
* Rich Felker [2016-03-10 18:28:20 -0500]:
> On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote:
> >
> > * Rich Felker wrote:
> >
> > > > So instead of a sticky cancellation flag, we could introduce a sticky
> > > > cancellation signal.
> > > >
> > > > A 'sticky signal' is not cleare
On Thu, Mar 10, 2016 at 07:03:31PM +0100, Ingo Molnar wrote:
>
> * Rich Felker wrote:
>
> > > So instead of a sticky cancellation flag, we could introduce a sticky
> > > cancellation signal.
> > >
> > > A 'sticky signal' is not cleared from signal_pending() when the signal
> > > handler
> >
* Rich Felker wrote:
> > So instead of a sticky cancellation flag, we could introduce a sticky
> > cancellation signal.
> >
> > A 'sticky signal' is not cleared from signal_pending() when the signal
> > handler
> > executes, but it's automatically blocked so no signal handler recursion
> >
On Thu, Mar 10, 2016 at 12:16:46PM +0100, Ingo Molnar wrote:
>
> * Rich Felker wrote:
>
> > [...]
> >
> > I believe a new kernel cancellation API with a sticky cancellation flag
> > (rather
> > than a signal), and a flag or'd onto the syscall number to make it
> > cancellable
> > at the call
* Rich Felker wrote:
> [...]
>
> I believe a new kernel cancellation API with a sticky cancellation flag
> (rather
> than a signal), and a flag or'd onto the syscall number to make it
> cancellable
> at the call point, could work, but then userspace needs to support fairly
> different old a
* Andy Lutomirski wrote:
> Let me try to summarize my understanding of the semantics.
>
> Thread A sends thread B a signal. Thread B wants to ignore the signal and
> defer
> handling unless it's either in a particular syscall and returns -EINTR or
> unless
> the thread is about to do the s
On Wed, Mar 09, 2016 at 11:47:30AM -0800, Linus Torvalds wrote:
> On Wed, Mar 9, 2016 at 3:34 AM, Szabolcs Nagy wrote:
> >>
> >> Could someone remind me why cancellation points matter to user-space?
> >
> > because of standards.
>
> So quite frankly, if we have to do kernel support for this, then
On Wed, Mar 9, 2016 at 12:57 PM, Andy Lutomirski wrote:
>
> How safe would this be in a multithreaded process? For example, if
> open() gets canceled in the "killable" sense, is it guaranteed that no
> file descriptor will be allocated?
Not all system calls can be killed, we only do the usual ca
On Wed, Mar 9, 2016 at 11:47 AM, Linus Torvalds
wrote:
> On Wed, Mar 9, 2016 at 3:34 AM, Szabolcs Nagy wrote:
>>>
>>> Could someone remind me why cancellation points matter to user-space?
>>
>> because of standards.
>
> So quite frankly, if we have to do kernel support for this, then let's
> do i
On Wed, Mar 9, 2016 at 3:34 AM, Szabolcs Nagy wrote:
>>
>> Could someone remind me why cancellation points matter to user-space?
>
> because of standards.
So quite frankly, if we have to do kernel support for this, then let's
do it right, instead of just perpetuating a hack that was done in user
* Szabolcs Nagy [2016-03-09 12:34:50 +0100]:
> * Ingo Molnar [2016-03-09 09:56:31 +0100]:
> > Why is so much complexity added to avoid a ~3 instructions window where
> > calcellation is tested? Cancellation at work atom boundaries is a
> > fundamentally
> > 'polling' model anyway, and signal d
* Ingo Molnar [2016-03-09 09:56:31 +0100]:
> * Andy Lutomirski wrote:
>
> > musl implements system call cancellation in an unusual but clever way.
>
> So I'm sceptical about the concept.
>
> Could someone remind me why cancellation points matter to user-space?
>
because of standards.
> I kn
30 matches
Mail list logo
