[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can we go GTK-only?
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: Can we go GTK-only? |
Date: |
Thu, 03 Nov 2016 12:43:18 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On Wed, 02 Nov 2016 17:46:26 +0200, Eli Zaretskii <address@hidden> said:
>> 1489 dispatch_group_async (group, queue, ^{
>> 1490 int nkeys;
>> 1491 uintptr_t key;
>> 1492 nkeys = nkeys_or_perm;
>> 1493 for (key = row * (256 / NGLYPHS_IN_VALUE); ; key++)
>> 1494 if (CFDictionaryContainsKey (dictionary,
>> 1495 (const void *) key))
>> 1496 {
>> 1497 CFDictionaryRemoveValue (dictionary,
>> 1498 (const void *) key);
>> 1499 if (--nkeys == 0)
>> 1500 break;
>> 1501 }
>> 1502 });
>>
>> I can disable this for NS if it does not fit with the current policy
>> of GNU Emacs mainline source code.
> I know next to nothing about NS. These are system APIs, right? If
> so, calling them could be okay, and I defer to NS and OS X people here
> to make that call.
They internally use malloc/free. What if the code like above were
using malloc/free instead of CF functions?
BTW, I just remember the current implementation of xfree should not be
used from a non-main thread if XMALLOC_BLOCK_INPUT_CHECK is defined.
The Mac port contains a code that calls "free" off the main thread for
some data that were allocated in the main thread.
void
mac_free_gc (GC gc)
{
CGColorRelease (gc->cg_fore_color);
CGColorRelease (gc->cg_back_color);
if (gc->clip_rects_data)
CFRelease (gc->clip_rects_data);
#if defined (XMALLOC_BLOCK_INPUT_CHECK) && DRAWING_USE_GCD
/* Don't use xfree here, because this might be called in a non-main
thread. */
free (gc);
#else
xfree (gc);
#endif
}
> One things bothers me, though: can't this arrangement, where data is
> allocated in one thread and deallocated in another, cause races? Or
> do these threads have means to synchronize between them?
For CFDictionary itself, its fundamental operations are thread-safe,
as well as malloc/free. For the font data structure that use
CFDictionary, the main thread waits for the other thread after doing
some independent tasks that do not use CFDictionary.
1543 if (group)
1544 {
1545 dispatch_group_wait (group, DISPATCH_TIME_FOREVER);
1546 dispatch_release (group);
1547 }
1548 }
YAMAMOTO Mitsuharu
address@hidden
- Re: Can we go GTK-only?, (continued)
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
- Re: Can we go GTK-only?, Daniel Colascione, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/01
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/02
- Re: Can we go GTK-only?, Daniel Colascione, 2016/11/02
- Re: Can we go GTK-only?, YAMAMOTO Mitsuharu, 2016/11/02
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/02
- Re: Can we go GTK-only?,
YAMAMOTO Mitsuharu <=
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/03
- Re: Can we go GTK-only?, Stefan Monnier, 2016/11/01
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/02
- Re: Can we go GTK-only?, Stefan Monnier, 2016/11/02
- Re: Can we go GTK-only?, Nikolaus Rath, 2016/11/02
- Re: Can we go GTK-only?, Paul Eggert, 2016/11/02
- Re: Can we go GTK-only?, Richard Stallman, 2016/11/02
- Re: Can we go GTK-only?, Nikolaus Rath, 2016/11/02
- Re: Can we go GTK-only?, Eli Zaretskii, 2016/11/02
- Re: Can we go GTK-only?, Perry E. Metzger, 2016/11/02