Re: native busy loop and thread-terminate!

--===============0561985555141580519==
Content-Type: multipart/alternative; boundary="0000000000003d1250062cf6727d"

--0000000000003d1250062cf6727d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The last pushed commit addresses the busy loop issue; thread-terminate!
sends a signal and wait a bit, and if the target is still running, sends
the signal again.  In the receiving side, if thread termination signal is
received while the previous one hasn't been processed, it terminates itself=
.

This does not address the cleanup issue.


On Tue, Jan 28, 2025 at 9:35=E2=80=AFAM Jens Thiele <[email protected]> wrote:

> Shiro Kawai <[email protected]> writes:
>
> > Aah, right. On Unix-based systems, thread-terminate! uses a signal to
> tell
> > the target to terminate.  It can't be intercepted by Scheme-level, but =
it
> > is still queued by the receiving side, and only becomes effective when
> the
> > thread calls Scm_SigCheck()---usually from the VM loop.
>
> > I think the supposed way is that C extension code needs to invoke
> > Scm_SigCheck() occasionally if it doesn't return control to Scheme.
>
> thanks!
> will try to use Scm_SigCheck. Looking at data.queue as example.
>
> > But that can't be enforced, especially if it's in the third party
> > code.
> >
> > We can employ a similar handling mechanism like typing ^C several times
> to
> > force gosh quit.  That is, thread-terminate! resends thread termination
> > signal after a short wait, and if the receiving side gets multiple
> > termination signal queued, it terminates the thread then.
>
> I see you created an issue for that:
> https://github.com/shirok/Gauche/issues/1106
>
> Jens
>
>
> _______________________________________________
> Gauche-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gauche-devel
>

--0000000000003d1250062cf6727d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The last pushed commit addresses the busy loop issue; thre=
ad-terminate! sends a signal and wait a bit, and if the target is still run=
ning, sends the signal again.=C2=A0 In the receiving side, if thread termin=
ation signal is received while the previous one hasn&#39;t been processed, =
it terminates itself.<div><br></div><div>This does not address the cleanup =
issue.</div><div><br></div></div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 28, 2025 at 9:=
35=E2=80=AFAM Jens Thiele &lt;<a href=3D"mailto:[email protected]">karme@karme=
.de</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Shiro Kawai &lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt; writes:<br>
<br>
&gt; Aah, right. On Unix-based systems, thread-terminate! uses a signal to =
tell<br>
&gt; the target to terminate.=C2=A0 It can&#39;t be intercepted by Scheme-l=
evel, but it<br>
&gt; is still queued by the receiving side, and only becomes effective when=
 the<br>
&gt; thread calls Scm_SigCheck()---usually from the VM loop.<br>
<br>
&gt; I think the supposed way is that C extension code needs to invoke<br>
&gt; Scm_SigCheck() occasionally if it doesn&#39;t return control to Scheme=
.<br>
<br>
thanks!<br>
will try to use Scm_SigCheck. Looking at data.queue as example.<br>
<br>
&gt; But that can&#39;t be enforced, especially if it&#39;s in the third pa=
rty<br>
&gt; code.<br>
&gt;<br>
&gt; We can employ a similar handling mechanism like typing ^C several time=
s to<br>
&gt; force gosh quit.=C2=A0 That is, thread-terminate! resends thread termi=
nation<br>
&gt; signal after a short wait, and if the receiving side gets multiple<br>
&gt; termination signal queued, it terminates the thread then.<br>
<br>
I see you created an issue for that:<br>
<a href=3D"https://github.com/shirok/Gauche/issues/1106" rel=3D"noreferrer"=
 target=3D"_blank">https://github.com/shirok/Gauche/issues/1106</a><br>
<br>
Jens<br>
<br>
<br>
_______________________________________________<br>
Gauche-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Gau=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/gauche-devel" rel=
=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/gauche-devel</a><br>
</blockquote></div>

--0000000000003d1250062cf6727d--


--===============0561985555141580519==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============0561985555141580519==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gauche-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gauche-devel

--===============0561985555141580519==--