Re: Building the igc branch on MS-Windows

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> >     void *extra;
>> 
>> What that is I have no idea. 
>
> See xftfont.c, which seems to be the only one using this.

Doesn't look like a reference to Lisp data to me, so I'd say we can
ignore it. Usual disclaimers.

> I added both ascii_font and extra to fix_face, but the segfault is
> still there.  What else can be done to dig into this crash?

Hm, I see nothing immediately obvious to do except collecting more info
where the font comes from.

>> While our scanning callbacks run, MPS guarantees us exclusive access to
>> only those objects in the address range MPS calls us for. All other
>> objects are (potentially) behind read/write barriers. So we can't change
>> something in object A while scanning a different object B.
>
> I don't understand what you are saying here, because there are too
> many unknowns: what are "our scanning callbacks"? what do you mean by
> "exclusive access"? what is "the address range MPS calls us for"? 

Ok, sorry.

Our scanning callbacks = functions we register with MPS: dflt_scan, the
various root scanning functions, like scan_staticvec ...

Exclusive access = other threads can't interfere

Address range MPS calls us for = the start and end address of the area
to scan are passed to dflt_scan, for example.

> what does "behind read/write barriers" mean in practice? and could you
> show a simple example of "can't change something in object A while
> scanning a different object B" -- what are object A and object B here?

The barries mean that we might get a SIGBUS or SIGSEGV when trying to
access something (read or write) outside of the scanned area (see
above).

I can't show an example, but maybe this help: Image we are scanning a
cons cell. We can then trace car and cdr as references, but we can't
follow the car and cdr to where tehy point. Let's say cdr is another
cons, then that cons is taboo.

>> This does not hold for objects that are not managed by MPS. If B has a
>> pointer to malloc'd memory M, we can do with M what we want, but MPS
>> also doesn't protect M from other threads. We're on our own.
>
> What "other threads"?

At the moment it's either the main thread or one of the threads created
with make-thread I think it is. Even if only one of these runs at a
time. The scanning is done concurrently in the MPS thread.