I rebuilt the gc-7.1 library, this time using the "--enable-threads=posix"
configure option. The exact same library was built. It would appear that
configure, at least on my target, enables threads by default.
On Mar 25, 2011, at 4:48 PM, michaelawells wrote:
>> On Fri 18 Mar 2011 12:51, address@hidden (Ludovic CourtÃs) writes:
>>
>> > michaelawells <address@hidden> writes:
>> >
>> >>> size_t len = SCM_HASHTABLE_N_ITEMS (table);
>> >>>
>> >>> while (k--)
>> >>> {
>> >>> size_t removed;
>> >>> SCM alist = SCM_SIMPLE_VECTOR_REF (buckets, k);
>> >>> alist = scm_fixup_weak_alist (alist, &removed); <<<**** FAILS HERE
>> >>> assert (removed <= len);
>> >
>> > Andy, isnât this assertion bogus since N_ITEMS is updated lazily and
>> > thus may not correspond to the current number of items?
>>
>> I don't think so; this is the procedure that is doing that lazy sweep.
>>
>> Michael, how are you using this hash table? Are you accessing it from
>> different pthreads? What version of libgc are you using? (Did you
>> enable parallel collection?)
> Sorry, the "<<<*** FAILS here" note should have been placed after the assert,
> not the call to "scm_fixup_weak_alist".
>
> I'm not using weak hash tables in my code. Weak hash tables are used in
> modules such as (ice-9 boot-9) and (ice-9 popen), and from C code, such as
> libguile/symbols.c.
>
> I'm using gc-7.1. I didn't use any special options when building libgc.
> I'll try rebuilding libgc using the "--enable-threads=posix" configure option
> and see if I still see the problem. (Is that what you meant by enabling
> parallel collection? If so, perhaps the README file should updated to say
> this is necessary.)
>
> I'm not using guile from multiple threads, but I am running guile from a
> thread in a multi-threaded program. (I've been using guile since before it
> had support for multiple threads. So, I constructed the test harness so that
> guile is called from a single thread.)
>
> Thanks,
>
> Michael Wells
>
