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 'map&= #39; pass-through an error from proc (and you don'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'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= <<a href=3D"mailto:[email protected]">[email protected]</a>> 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 <<a hre= f=3D"mailto:[email protected]" target=3D"_blank">[email protected]<= /a>> writes:<br> <br> > Regarding pmap semantics in case of uncaught exception, it is not defi= ned<br> > at all; I guess I thought to leave the caller handle any exceptions wi= thin<br> > proc, but that'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'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'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't help either.<br> <br> > I'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==--