summaryrefslogtreecommitdiff
path: root/source/fitz/harfbuzz.c
blob: 9afd9e409f0923891154e63783f4b31176100650 (plain)
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
126
/*
 * 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);
}