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

[Jose E. Marchesi]

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

Also, I would conditionally compile off the whole ctrlc thread logic,
not just the single calls to the pthread interface.

Thanks!