Am Donnerstag, den 07.08.2008, 12:03 -0400 schrieb John Cowan: > Vincent Manis scripsit: > > > I'd prefer to have the manual document that to the best of our knowledge > > thread-terminate works `correctly', but that its use is fraught with > > design and testing problems, and therefore it should be avoided. > > I'd go even further: KILL THE BEAST.
Do whatever you feel appropriate. ;-) Since chicken has thread-signal! [now ;-) when some hacker, who's well known on this list, suggested to use thread-terminate! to limit the real time a thunk takes, it had not] Hence I do not depend on thread-terminate! anymore. Though I know that the program I'm porting works fine, if thread-terminate! does (at least) abandon all mutex's the thread holds and removes it properly from any queue/port it might be waiting on etc. I'm not yet sure, that it still works fine, when those threads get the chance to properly clean up after themself - after all, they could not, while the Scheme system easily can [though this is not trivial]. Nevertheless, I would not remove thread-terminate! Maybe repeat in the manual those warnings from SRFI-18 that this is not exactly a nice call to make. But why support half a srfi? Furthermore: I do understand those issues about thread being left in inconsistent state (not that bad when they are terminated anyway) and worse inconsistent data structures. Looking at compatibility issues, I can't see a SRFI-18 compatible way to interrupt a thead except thread-terminate! . That's basically the challenge I'm facing: I have some user supplied code (which, being user supplied, might endless loop), which I want to run for a limited amount of time until I decide to terminate the computation. How would I do that? }}8-[ _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
