Re: [Linuxtuples-devel] race condition in dump op

[Will W. <ww...@al...>]

On 5/10/06, Bram Stolk <br...@sa...> wrote:
> I stumbled upon another race condition.
> when tuples are removed between unlock and sending, their
> memory can be freed, causing a 'Bad address' in the send() syscall.
> The fix is to move the YIELDACCESS down (and do it twice: also in
> early return).

Alternatively, we could do reference counting on tuples, so that we
didn't have to lock the whole space for all that time. Dumping is
something you'd do when debugging the space, and hopefully an
infrequent occurrence, so the effort of adding reference counts is
probably not warranted.

> I cannot commit to cvs, as cvs is now completely gone: both
> developer cvs and user cvs are not working.

It doesn't work for me either. Sourceforge also offers Subversion as
an alternative to CVS. I understand that Subversion has many features
and improvements that make it better than CVS, but I think the problem
we are both having at the moment is due to server downtime, not
deficiencies in CVS. Switching to Subversion wouldn't guarantee more
server uptime.

Info about Subversion on Sourceforge
http://sourceforge.net/docman/display_doc.php?docid=3D31070&group_id=3D1

I think I'll need some time to wrap my brain around Subversion. It's
one of those things I've intended to learn about for a while. I have
no problem with migrating from CVS to Subversion but I am not prepared
to do it immediately.

Will Ware