On 01/25/21 22:13, Laszlo Ersek wrote:
> On 01/23/21 23:13, Paolo Bonzini wrote:
>> On 22/01/21 22:26, Laszlo Ersek wrote:
>>> That seems bogus, per POSIX, given that all signals except SIGUSR2 are
>>> included in the mask passed to sigsuspend().
>>
>> What happens if you get a SIGSTOP at exactly t
On 01/25/21 11:57, Max Reitz wrote:
> On 23.01.21 01:41, Laszlo Ersek wrote:
>> On 01/22/21 22:26, Laszlo Ersek wrote:
>>
>>> I'm drifting towards an overhaul of coroutine-sigaltstack, based on my
>>> personal understanding of POSIX, but given that I can absolutely not
>>> *test* coroutine-sigaltst
On 01/23/21 23:13, Paolo Bonzini wrote:
> On 22/01/21 22:26, Laszlo Ersek wrote:
>> That seems bogus, per POSIX, given that all signals except SIGUSR2 are
>> included in the mask passed to sigsuspend().
>
> What happens if you get a SIGSTOP at exactly the wrong time? (Yeah I
> know how incredibly
On 23.01.21 01:41, Laszlo Ersek wrote:
On 01/22/21 22:26, Laszlo Ersek wrote:
I'm drifting towards an overhaul of coroutine-sigaltstack, based on my
personal understanding of POSIX, but given that I can absolutely not
*test* coroutine-sigaltstack on the platforms where it actually matters,
an "
On 22/01/21 22:26, Laszlo Ersek wrote:
That seems bogus, per POSIX, given that all signals except SIGUSR2 are
included in the mask passed to sigsuspend().
What happens if you get a SIGSTOP at exactly the wrong time? (Yeah I
know how incredibly unlikely that would be).
BTW if we are in a moo
On 01/22/21 22:26, Laszlo Ersek wrote:
> I'm drifting towards an overhaul of coroutine-sigaltstack, based on my
> personal understanding of POSIX, but given that I can absolutely not
> *test* coroutine-sigaltstack on the platforms where it actually matters,
> an "overhaul" by me would be reckless.
On 01/22/21 19:29, Laszlo Ersek wrote:
> OK, I'll try my hand at it; I hope I won't be eating my words.
The more I look at it, the less comfortable I am with the existent code.
For example, I don't understand why the original commit -- 3194c8ceeba0,
"coroutine: adding sigaltstack method (.c sour
On 01/22/21 18:58, Max Reitz wrote:
> On 22.01.21 17:38, Laszlo Ersek wrote:
>> (1) With SIGUSR2 permanently dedicated to "coroutine-sigaltstack.c", the
>> comment on the qemu_init_main_loop() declaration, in
>> "include/qemu/main-loop.h", also needs to be updated. SIGUSR2 is no
>> longer a "free
On 01/22/21 19:19, Eric Blake wrote:
> On 1/22/21 11:58 AM, Max Reitz wrote:
>
+ if (!self) {
+ /*
+ * This SIGUSR2 came from an external source, not from
+ * qemu_coroutine_new(), so perform the default action.
+ */
+ exit(0);
On 01/22/21 19:05, Max Reitz wrote:
> On 22.01.21 18:09, Laszlo Ersek wrote:
>> On 01/22/21 11:20, Max Reitz wrote:
>>> Modifying signal handlers is a process-global operation. When two
>>> threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
>>> they may interfere with each othe
On 01/22/21 18:58, Max Reitz wrote:
> On 22.01.21 17:38, Laszlo Ersek wrote:
>> On 01/22/21 11:20, Max Reitz wrote:
>>> Modifying signal handlers is a process-global operation. When two
>>> threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
>>> they may interfere with each othe
On 1/22/21 11:58 AM, Max Reitz wrote:
>>> + if (!self) {
>>> + /*
>>> + * This SIGUSR2 came from an external source, not from
>>> + * qemu_coroutine_new(), so perform the default action.
>>> + */
>>> + exit(0);
>>> + }
>>
>> (2) exit() is generally unsaf
On 22.01.21 18:09, Laszlo Ersek wrote:
On 01/22/21 11:20, Max Reitz wrote:
Modifying signal handlers is a process-global operation. When two
threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
they may interfere with each other: One of them may revert the SIGUSR2
handler back
On 22.01.21 17:38, Laszlo Ersek wrote:
On 01/22/21 11:20, Max Reitz wrote:
Modifying signal handlers is a process-global operation. When two
threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
they may interfere with each other: One of them may revert the SIGUSR2
handler back
On 01/22/21 11:20, Max Reitz wrote:
> Modifying signal handlers is a process-global operation. When two
> threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
> they may interfere with each other: One of them may revert the SIGUSR2
> handler back to the default between the other
On 01/22/21 11:20, Max Reitz wrote:
> Modifying signal handlers is a process-global operation. When two
> threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
> they may interfere with each other: One of them may revert the SIGUSR2
> handler back to the default between the other
On 1/22/21 4:20 AM, Max Reitz wrote:
> Modifying signal handlers is a process-global operation. When two
> threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
> they may interfere with each other: One of them may revert the SIGUSR2
> handler back to the default between the other
Modifying signal handlers is a process-global operation. When two
threads run coroutine-sigaltstack's qemu_coroutine_new() concurrently,
they may interfere with each other: One of them may revert the SIGUSR2
handler back to the default between the other thread setting up
coroutine_trampoline() as
18 matches
Mail list logo
