Re: thread resource leaks if thread terminates with uncaught exception

Shiro Kawai <[email protected]> Fri, 10 Jan 2025 05:55:29 -1000
Newsgroups gmane.lisp.scheme.gauche
Message-ID <CALN0JNG4N8xkPeziodNNGqDMBs4RVMC19xxhvu9Y5Det7+=mDQ@mail.gmail.com>
--===============9104508882024472648==
Content-Type: multipart/alternative; boundary="00000000000063bf14062b5c20cd"

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

Your point that pmap should be able to be used just like a parallel version
of map, is valid.  It should be.
Since 'map' pass-through an error from proc (and you don't know which
iteration the proc throws it), I think it is ok that pmap throws just one
of the errors.  The point is to ensure thread-join! is called on all the
threads.  I'll make that change first.



On Fri, Jan 10, 2025 at 3:51=E2=80=AFAM Jens Thiele <[email protected]> wrote:

> Shiro Kawai <[email protected]> writes:
>
> > Regarding pmap semantics in case of uncaught exception, it is not defin=
ed
> > at all; I guess I thought to leave the caller handle any exceptions
> within
> > proc, but that's probably a bad API.
>
> From a user point of view it is tempting to have it as close as possible
> to map. Then one could add a p here and there to parallelize. But maybe
> this is just a dangerous/bad invitation. I am really not sure what
> should happen in the case with multiple uncaught exceptions. Collecting
> them and returning them doesn't look that nice either (and what about
> the terminated threads)?. Picking one exception raises the question
> which one? Are there exceptions more important than others? And ignoring
> exceptions doesn't feel right. Maybe it really should be the callers job
> as you write.
>
> A quick search how others do that, didn't help either.
>
> > I'll come back regarding the resource leak.
>
> thanks
>
> Jens
>
>
> _______________________________________________
> Gauche-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gauche-devel
>

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

<div dir=3D"ltr">Your point that pmap should be able to be used just like a=
 parallel version of map, is valid.=C2=A0 It should be.<div>Since &#39;map&=
#39; pass-through an error from proc (and you don&#39;t know which iteratio=
n the proc throws it), I think it is ok that pmap throws just one of the er=
rors.=C2=A0 The point is to ensure thread-join! is called on all the thread=
s.=C2=A0 I&#39;ll make that change first.</div><div><br></div><div><br></di=
v></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"lt=
r" class=3D"gmail_attr">On Fri, Jan 10, 2025 at 3:51=E2=80=AFAM Jens Thiele=
 &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Shiro Kawai &lt;<a hre=
f=3D"mailto:[email protected]" target=3D"_blank">[email protected]<=
/a>&gt; writes:<br>
<br>
&gt; Regarding pmap semantics in case of uncaught exception, it is not defi=
ned<br>
&gt; at all; I guess I thought to leave the caller handle any exceptions wi=
thin<br>
&gt; proc, but that&#39;s probably a bad API.<br>
<br>
From a user point of view it is tempting to have it as close as possible<br=
>
to map. Then one could add a p here and there to parallelize. But maybe<br>
this is just a dangerous/bad invitation. I am really not sure what<br>
should happen in the case with multiple uncaught exceptions. Collecting<br>
them and returning them doesn&#39;t look that nice either (and what about<b=
r>
the terminated threads)?. Picking one exception raises the question<br>
which one? Are there exceptions more important than others? And ignoring<br=
>
exceptions doesn&#39;t feel right. Maybe it really should be the callers jo=
b<br>
as you write.<br>
<br>
A quick search how others do that, didn&#39;t help either.<br>
<br>
&gt; I&#39;ll come back regarding the resource leak.<br>
<br>
thanks<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>

--00000000000063bf14062b5c20cd--


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


--===============9104508882024472648==
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

--===============9104508882024472648==--