Re: thread resource leaks if thread terminates with uncaught exception
Shiro Kawai <[email protected]> Fri, 10 Jan 2025 21:33:49 -1000
| Newsgroups | gmane.lisp.scheme.gauche |
|---|---|
| Message-ID | <CALN0JNGr8Dgo_OGoXx8_JCgtaw440VvP67d8X+cqsXKUYWJ_qQ@mail.gmail.com> |
--===============4561591220219506916== Content-Type: multipart/alternative; boundary="0000000000002193dd062b693c70" --0000000000002193dd062b693c70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I pushed a fix of pmap to ensure all worker threads are joined. Seems to be working with simple manual tests. It's a bit difficult to write an automated test for it, though. On Fri, Jan 10, 2025 at 5:55=E2=80=AFAM Shiro Kawai <[email protected]>= wrote: > 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]> wrot= e: > >> Shiro Kawai <[email protected]> writes: >> >> > Regarding pmap semantics in case of uncaught exception, it is not >> defined >> > 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 >> > --0000000000002193dd062b693c70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I pushed a fix of pmap to ensure all worker threads are jo= ined.=C2=A0 Seems to be working with simple manual tests.=C2=A0 It's a = bit difficult to write an automated test for it, though.</div><br><div clas= s=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_att= r">On Fri, Jan 10, 2025 at 5:55=E2=80=AFAM Shiro Kawai <<a href=3D"mailt= o:[email protected]">[email protected]</a>> wrote:<br></div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left= :1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Your point t= hat pmap should be able to be used just like a parallel version of map, is = valid.=C2=A0 It should be.<div>Since 'map' pass-through an error fr= om proc (and you don't know which iteration the proc throws it), I thin= k it is ok that pmap throws just one of the errors.=C2=A0 The point is to e= nsure thread-join! is called on all the threads.=C2=A0 I'll make that c= hange first.</div><div><br></div><div><br></div></div><br><div class=3D"gma= il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jan 10, 2025 at 3:5= 1=E2=80=AFAM Jens Thiele <<a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex">Shiro Kawai <<a href=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> </blockquote></div> --0000000000002193dd062b693c70-- --===============4561591220219506916== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4561591220219506916== 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 --===============4561591220219506916==--