On Mon, Jul 27, 2009 at 11:44 PM, Madhan Sadasivam wrote:
> When is this release expected.
> This solves a long standing problem for me.
Mid-August, hopefully.
Nick
--
Let Crystal Reports handle the reporting - Free Crys
When is this release expected.
This solves a long standing problem for me.
Thanks,
Madhan.
On Mon, Jul 27, 2009 at 3:14 PM, Julian Seward wrote:
> On Monday 27 July 2009, Patrick Smears wrote:
> > On Fri, 24 Jul 2009, Patrick Smears wrote:
> > > On Fri, 24 Jul 2009, Julian Seward wrote:
> > >>>
On Monday 27 July 2009, Patrick Smears wrote:
> On Fri, 24 Jul 2009, Patrick Smears wrote:
> > On Fri, 24 Jul 2009, Julian Seward wrote:
> >>> anyone change it between comparing it to A and setting it to B).
> >>> Because of the way Valgrind works (simulating instructions), the atomic
> >>> instruc
On Fri, 24 Jul 2009, Patrick Smears wrote:
> On Fri, 24 Jul 2009, Julian Seward wrote:
>
>>
>>> anyone change it between comparing it to A and setting it to B). Because
>>> of the way Valgrind works (simulating instructions), the atomic
>>> instructions get broken up into separate loads/stores,
On Friday 24 July 2009, Jeroen N. Witmond [Bahco] wrote:
> Julian Seward wrote:
> > Not really. On x86 and amd64, all atomic instructions are translated
> > using a loop, which fetches the old value, computes the new value, and
> > uses a compare-and-swap to either stuff the new value in, or detec
Julian Seward wrote:
>
> Not really. On x86 and amd64, all atomic instructions are translated
> using a loop, which fetches the old value, computes the new value, and
> uses a compare-and-swap to either stuff the new value in, or detect that
> the old value has changed, in which case it starts ove
> > That's fixed now, in the trunk (not 3.4.x). If you put in atomic
> > instructions then you should get out (something equivalent to)
> > atomic instructions. So V should now play nice with other processes
> > communicating via shared memory.
>
> Cool, that's good to know :) Is there a place I
On Fri, 24 Jul 2009, Julian Seward wrote:
>
>> anyone change it between comparing it to A and setting it to B). Because
>> of the way Valgrind works (simulating instructions), the atomic
>> instructions get broken up into separate loads/stores, meaning that
>> they're no longer atomic (i.e. it's
> anyone change it between comparing it to A and setting it to B). Because
> of the way Valgrind works (simulating instructions), the atomic
> instructions get broken up into separate loads/stores, meaning that
> they're no longer atomic (i.e. it's possible for someone to change the
> location in
OK - to follow up on a blast from the past:
On Tue, 11 Dec 2007, Patrick Smears wrote:
> Hi all,
>
>> Sorry not to have been very inputful on this so far.
>>
>> I can't claim to have great insight into the robustness aspects
>> of the NON_SIMD_CALL mechanism. However, looking at your original
10 matches
Mail list logo
