When to free the desc in a multithreaded driver

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

When to free the desc in a multithreaded driver

Sean Hinde-2
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?

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

Thanks,
Sean

----------------------------------------------
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;
}



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.



Reply | Threaded
Open this post in threaded view
|

When to free the desc in a multithreaded driver

Raimo Niskanen-3
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;
> }
>


Reply | Threaded
Open this post in threaded view
|

Anticipating R8 / Was: Re: When to free the desc in a multithreaded driver

snickl
On Wed, 22 Aug 2001, Raimo Niskanen wrote:

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

Just being curious, but what will be the "great new features" in R8?
Is there anything online I didn't see yet?
Is the preview at EUC'2001 going to be put up afterwards?

Impatient in Bavaria,

CU, SN
------
The UNIX equivalent of the "Blue Screen of Death" would be called
"kernel panic". It obviously exists, since I have heard and read about it,
but I've never been witness to it in my professional career.
        John Kirch,
        Networking Consultant and Microsoft Certified Professional (Windows NT)