Re: to-be-closed variables as resources from a library.

[Jorge Visca <xxopxe@...>]

On 29/9/22 13:31, Francisco Olarte wrote:
> More or less, this takes a minimum discipline on your users, but
> dealing with finite resources is not for the faint of heart.

The library I was thinking of is a multitasking scheduler, so one on the 
objects the library produces are tasks (coroutines). It's a resource 
that is not scarce, but it is "expensive" in the sense that it might be 
doing something computationally expensive or lock some resource itself 
(like TCP connections). The risk is orphaned tasks.

What the library does today is to allow the users to attach a task to 
another, so when a task is kill() 'ed or errors all the related tasks 
are killed by the scheduler automatically. Of course this depends on the 
user taking the time to configure this right, and is explicit.

What I meant with using <close> inside the library is that if the 
library offered a call like eg wait_for_all_to_finish(f1, f2,...) and 
the tasks where created inside the library, it could use <close> because 
it could make sure the tasks do no leak outside.

The library is for use for not very savvy/disciplined programmers (grad 
students, electrical engineers, ...). Basically people who would seek 
out an example that suits them, adapt it and if it "works" would not 
check the docs at all. So I was looking for the safest environment. I'm 
gravitating to explicit close(), __gc()+weak links for safety, __close() 
for fine tuning and careful users, and well designed patterns offered by 
the library that take advantage of <close>.

Thanks for all the food for thought.


Jorge