When to free the desc in a multithreaded driver

[Raimo Niskanen]

Sean Hinde wrote:
> 
> Hi,
> 
> Looking at the file driver, efile_drv.c, I can't quite determine when the
> port descriptor gets freed.
> 
> In the file_stop() callback, which I have attached below, the desc gets
> freed if the fd is zero or the file is compressed, but if the fd is not zero
> then an invoke_close callback is scheduled. I can't then see anywhere else
> that the desc gets freed.
> 
> Two questions arise:
> 
> 1. If the driver stop callback invokes a function in a thread when should
> the descriptor be freed?
> 

The descriptor should be freed in the driver stop callback.

When the async operation is finished, the driver async_ready callback
cannot be called since the port has been closed, so the free_data
function is called to free the thread specific data.

This is tricky programming. It is much nicer to avoid starting async
requests in the driver stop callback.



> 2. Depending on the answer to 1, is there therefore a memory leak in
> efile_drv?
> 

Yes. This is already corrected in the coming R8 release, and we are
working on a patch for R7B shortly.


/ Raimo Niskanen, Erlang/OTP, Ericsson UAB



> 
> ----------------------------------------------
> static int file_stop(desc)
> file_descriptor* desc;
> {
>     int fd = desc->fd;
> 
>     if (desc->flags & EFILE_COMPRESSED) {
>         gzclose((gzFile)fd);
>     } else if (fd >= 0) {
> #if 0
>         efile_closefile(fd);
> #else
> /* Threaded close */
>     {
>         struct t_data *d = sys_alloc(sizeof(struct t_data));
>         d->fd = fd;
>         d->command = FILE_CLOSE;
>         DRIVER_ASYNC(2, desc, KEY, invoke_close, (void *) d,
>                      free_data);
>         return 0;
>     }
> #endif
>     }
>     sys_free(desc);
>     return 0;
> }
>