[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] Filters deallocation
From: |
gerel |
Subject: |
Re: [pdf-devel] Filters deallocation |
Date: |
Thu, 25 Sep 2008 08:48:47 -0700 (PDT) |
> Date: Wed, 24 Sep 2008 16:20:05 +0200
> From: Juan Pedro Bolivar Puente <address@hidden>
>
> address@hidden wrote:
> > Hi Gerel.
> >
> > I think the Stream module documentation is missing the deallocation
> > operation,
> > the one that deallocs the memory used by the filter itself.
> > ##
> > pdf_status_t pdf_stm_f_somefilter_dealloc (void **state);
> > ###
> >
> > As I mentioned in a previous email the pdf_stm_destroy() operation
> > will take care about the memory used by 'state' (if any) by calling
> > pdf_dealloc.
> >
> >
>
> Is that enough? What if the 'state' contains non-trivial data structures?
>
> Another question, after having received a finish_p in an apply, does the
> possibility exist of receiving more data in the future? If that is true
> (it could allow more freedom)
>
> I suggest a new interface with 5 operations defined by the filter
> (params ommited):
Hey JP,
I don't know if that schema makes a difference. To me the most difficult thing
when writing the RL filter, was dealing with the trailing character AND the
output bytes available, that's why I set a minimum cache size (i.e. the maximum
bytes you would be forced to write when finishing) for it. And I guess you can't
avoid that, the finish function you suggest should do a 'filter flush' anyways.
cheers
-gerel