Re: [PATCH] poke: use pthread functions only if available

[Jose E. Marchesi]

>  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.

Thank you!

>> 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.

Ok then.