corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: Request for review: branch RTC_platform
Date Thu, 01 Jan 2015 10:43:14 GMT
> On 1 Jan 2015, at 5:20 pm, jan i <> wrote:
> Hi.
> platform/src/wrapper.c
> platform/headers/DFPlatform.h
> core/src/lib/DFZipFile.c
> need a review before committing. We have API changes (minizip is isolated)
> and before committing I would like to hear others opinion.
> I have (based on a good hint from dennis) created origin/RTC_platform with
> all the changes. Feel free to make changes directly there or discuss it
> here.

I don’t understand the rationale behind this - DFZipFile already provided an abstraction
layer over minizip (in the sense that this is the only file that used any minizip data types/functions).

> I have on purpose limited the zip API to only handle one zip file....If we
> one day decide to go multithreaded (in contradiction to multi process) we
> need to make the variabels in wrapper.c thread_local (which is easy).

It needs to be multithreaded - UX Write already depends on this and the old API worked fine
- in fact that’s the whole reason DFZipeFile exists. The minizip API already provides an
handle object with which you can have multiple zip files open concurrently (in the same or
different threads), and if we’re going to replicate the minizip API we should at minimum
keep this capability.

An example of where you might want two zip files open at the same time is if you’re converting
from .docx to .odt. While the current implementation reads the whole source file into memory,
an optimisation that would be very useful for files containing large images is to have it
only read the contents on demands. So during a conversion you would have an input zip file
handle and an output zip file handle. Thread-locals will not solve this problem.

Dr Peter M. Kelly

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message