1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
/*
* Some additional glue functions for using Harfbuzz with
* custom allocators.
*/
#include "mupdf/fitz.h"
#include "hb.h"
/* Harfbuzz has some major design flaws.
*
* It is utterly thread unsafe. It uses statics to hold
* structures in, meaning that if it is ever called from
* more than one thread at a time, access to such
* structures can race. We work around this by imposing
* a lock on our calls to harfbuzz (we reuse the freetype
* lock).
*
* This does not protect us against the possibility of
* other people calling harfbuzz; for instance, if we
* link MuPDF into an app that either calls harfbuzz
* itself, or uses another library that calls harfbuzz,
* there is no guarantee that that library will take
* the same lock while calling harfbuzz. This leaves
* us open to the possibility of crashes. The only
* way around this would be to use completely separate
* harfbuzz instances.
*
* In order to ensure that allocations throughout mupdf
* are done consistently, we get harfbuzz to call our
* own hb_malloc/realloc/calloc/free functions that
* call down to fz_malloc/realloc/calloc/free. These
* require context variables, so we get our hb_lock
* and unlock to set these. Any attempt to call through
* without setting these is detected.
*
* It is therefore vital that any fz_lock/fz_unlock
* handlers are shared between all the fz_contexts in
* use at a time.
*
* Finally, harfbuzz stores various malloced structures
* in statics. These can either be left to leak on
* closedown, or (if HAVE_ATEXIT is defined), they will
* be freed using various 'atexit' callbacks. Unfortunately
* this won't reset the fz_context value, so the allocators
* can't free them correctly.
*
* Consequently, we leave them to leak, and warn Memento
* about this.
*/
/* Potentially we can write different versions
* of get_context and set_context for different
* threading systems.
*
* This simple version relies on harfbuzz never
* trying to make 2 allocations at once on
* different threads. The only way that can happen
* is when one of those other threads is someone
* outside MuPDF calling harfbuzz while MuPDF
* is running. This will cause us such huge
* problems that for now, we'll just forbid it.
*/
static fz_context *hb_secret = NULL;
static void set_context(fz_context *ctx)
{
hb_secret = ctx;
}
static fz_context *get_context()
{
return hb_secret;
}
void hb_lock(fz_context *ctx)
{
fz_lock(ctx, FZ_LOCK_FREETYPE);
set_context(ctx);
}
void hb_unlock(fz_context *ctx)
{
set_context(NULL);
fz_unlock(ctx, FZ_LOCK_FREETYPE);
}
void *hb_malloc(size_t size)
{
fz_context *ctx = get_context();
assert(ctx != NULL);
return fz_malloc_no_throw(ctx, size);
}
void *hb_calloc(size_t n, size_t size)
{
fz_context *ctx = get_context();
assert(ctx != NULL);
return fz_calloc_no_throw(ctx, n, size);
}
void *hb_realloc(void *ptr, size_t size)
{
fz_context *ctx = get_context();
assert(ctx != NULL);
return fz_resize_array_no_throw(ctx, ptr, 1, size);
}
void hb_free(void *ptr)
{
fz_context *ctx = get_context();
assert(ctx != NULL);
fz_free(ctx, ptr);
}
|
