[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] poke: use pthread functions only if available
From: |
Hannes Domani |
Subject: |
Re: [PATCH] poke: use pthread functions only if available |
Date: |
Thu, 22 Feb 2024 13:46:02 +0000 (UTC) |
Am Donnerstag, 22. Februar 2024 um 14:31:37 MEZ hat Jose E. Marchesi
<jemarch@gnu.org> Folgendes geschrieben:
> > Am Mittwoch, 21. Februar 2024 um 16:57:27 MEZ hat Hannes Domani via
> > poke-devel <poke-devel@gnu.org> Folgendes geschrieben:
> >
> >> Am Mittwoch, 21. Februar 2024 um 16:30:41 MEZ hat Jose E. Marchesi
> >> <jemarch@gnu.org> Folgendes geschrieben:
> >>
> >> > > Am Mittwoch, 21. Februar 2024 um 11:47:54 MEZ hat Jose
> >> > > E. Marchesi <jemarch@gnu.org> Folgendes geschrieben:
> >> > >
> >> > >> Hi Hannes.
> >> > >>
> >> > >> Thanks for the patch.
> >> > >>
> >> > >> How does poke handle ctrl-C in the Windows terminal with this patch
> >> > >> applied? Does it get back to the (poke) prompt or kills the process?
> >> > >
> >> > > If you press ctrl-c when no poke command is currently executing,
> >> > > nothing
> >> > > happens.
> >> > > If you press ctrl-c while a poke command is processing, it immediately
> >> > > stops
> >> > > and goes back to the (poke) prompt (apparently pvm_handle_signal does
> >> > > this).
> >> >
> >> > Yes, that covers when you press Ctrl-C while executing the PVM. Like
> >> > for example if you do:
> >> >
> >> > (poke) while (1) {}
> >> > <Ctrl-c>
> >> >
> >> > On the other side, poke_sigint_handler is invoked when the PVM is not
> >> > executing, i.e. when Poke code is not running. Like in:
> >> >
> >> > (poke) type this then press ctrl-c^C
> >> >
> >> > (poke) _
> >> >
> >> >
> >> > i.e. the signal handler removes the current text at the prompt and then
> >> > draws a prompt again. I expect your patch to impact this second case.
> >>
> >> OK, so that's what this signal handling is for, you're right, this case
> >> doesn't work, nothing at all happens if you press ctrl-c in the prompt.
> >>
> >> I'll see if I can fix this.
> >
> > So it's not possible to handle ctrl-c the same way on windows, since
> > the signal handler is always called in a new thread there.
> > Though I don't think that this should stop us from getting this in, most
> > people probably wouldn't even notice that this is missing (I didn't).
>
> Yes I agree. But it was worth it to see if this could be supported
> somehow. Pity :)
>
> > I'm just not completely sure if the check via #ifdef HAVE_PTHREAD_H is
> > fine, or if I should use #ifndef _WIN32, or something else, instead.
>
> I would check for target (_WIN32). We may at some point start using the
> gnulib support for portable threads.
Ok, will do.
> Also, I would conditionally compile off the whole ctrlc thread logic,
> not just the single calls to the pthread interface.
I thought I did.
I just checked again, and still don't see what I missed.
Hannes
- [PATCH] poke: use pthread functions only if available, Hannes Domani, 2024/02/15
- Re: [PATCH] poke: use pthread functions only if available, Jose E. Marchesi, 2024/02/21
- Re: [PATCH] poke: use pthread functions only if available, Hannes Domani, 2024/02/21
- Re: [PATCH] poke: use pthread functions only if available, Jose E. Marchesi, 2024/02/21
- Re: [PATCH] poke: use pthread functions only if available, Hannes Domani, 2024/02/21
- Re: [PATCH] poke: use pthread functions only if available, Hannes Domani, 2024/02/21
- Re: [PATCH] poke: use pthread functions only if available, Jose E. Marchesi, 2024/02/22
- Re: [PATCH] poke: use pthread functions only if available,
Hannes Domani <=
- Re: [PATCH] poke: use pthread functions only if available, Jose E. Marchesi, 2024/02/22