Re: [Chicken-users] problem building chicken 4.8.0.3 on mac 10.4
Hi! Using GNU Make 3.81 indeed solves the problem. Still I wonder what the problem is. This used to work, especially on said machine... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] problem building chicken 4.8.0.3 on mac 10.4
Was that prior to the makefiles being completely rewritten, though? Maybe the rewrite uses a feature not available until 3.81, rather than being a bug in 3.80. On Jun 4, 2013, at 9:46, Felix fe...@call-with-current-continuation.org wrote: Hi! Using GNU Make 3.81 indeed solves the problem. Still I wonder what the problem is. This used to work, especially on said machine... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] problem building chicken 4.8.0.3 on mac 10.4
From: Jim Ursetto zbignie...@gmail.com Subject: Re: [Chicken-users] problem building chicken 4.8.0.3 on mac 10.4 Date: Tue, 4 Jun 2013 12:12:37 -0500 Was that prior to the makefiles being completely rewritten, though? Maybe the rewrite uses a feature not available until 3.81, rather than being a bug in 3.80. Yes, I guess this is the case. The makefiles used to be really ugly, but simple, using no hacks, just a lot of duplication. Refactoring over time has added more and more metaprogramming hacks (eval, call, etc.), which may not be supported on older make versions. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] set! atomic?
SRFI-18 states: Read and write operations on the store (such as reading and writing a variable, an element of a vector or a string) are not required to be atomic. It is an error for a thread to write a location in the store while some other thread reads or writes that same location. Is it possible to eval a variable that is in an inconsistent state? I understand that if there are a series of set-car! on a list, then a reader may see the list as it is in between any of the set-car! calls. But is it possible that an update to a very large object will ever be interrupted by one thread such that other threads will see a broken version? (use srfi-1) (define foo '(1 2 3)) (thread-start! (make-thread (lambda () (set! foo (iota 1e8) (print foo) In the above code, will the primordial thread ever print a list that isn't exactly (1 2 3) or (iota 1e8)? The context of my question is that for a small web app I have a hash table that all threads read freely, but they coordinate writes with a mutex. Do I need to also have a read lock? Bryan Vicknair ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] set! atomic?
Yes, many mutate operations are not srfi-18 threads aware, in my (possibly incorrect) experience. Also, just as an FYI, Chicken's SRFI-18 threads are not system threads, and so cannot avail themselves of additional processors. If real parallel operations are your goal then you'll want to look at process forking. posix, posix-shm, posix-semaphore and lolevel's object-evict (or the new protobuf) should be helpful in this regard. -Dan On 13-06-04 07:15 PM, Bryan Vicknair wrote: SRFI-18 states: Read and write operations on the store (such as reading and writing a variable, an element of a vector or a string) are not required to be atomic. It is an error for a thread to write a location in the store while some other thread reads or writes that same location. Is it possible to eval a variable that is in an inconsistent state? I understand that if there are a series of set-car! on a list, then a reader may see the list as it is in between any of the set-car! calls. But is it possible that an update to a very large object will ever be interrupted by one thread such that other threads will see a broken version? (use srfi-1) (define foo '(1 2 3)) (thread-start! (make-thread (lambda () (set! foo (iota 1e8) (print foo) In the above code, will the primordial thread ever print a list that isn't exactly (1 2 3) or (iota 1e8)? The context of my question is that for a small web app I have a hash table that all threads read freely, but they coordinate writes with a mutex. Do I need to also have a read lock? Bryan Vicknair ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
