[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dev-serveez] Small patch (bugfixes)

From: Andreas Rottmann
Subject: Re: [dev-serveez] Small patch (bugfixes)
Date: 22 Dec 2002 16:42:51 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

stefan <address@hidden> writes:

> On 19 Dec 2002, Andreas Rottmann wrote:
> > Hi!
> Hello!
> > I discovered two bugs in serveez:
> >
> > 1) in coserver.c, coserver->sock was not initialized (thanks to
> >    valgrind for pointing this out ;-))
> >
> > 2) svz_sock_reduce_{send,recv}: These macros did not bracket the
> >    arguments wich leads to unexpected results. example: if you passed
> >    'a + b' for len, this would have been expanded to:
[snip explanation]

> > Maybe you should check all other macros too. [...] The attached
> > patch (against CVS) fixes the above bugs and also notes the
> > changes in the ChangeLog.
> Thank you very much for the report.  I'll apply the bugfix ASAP (This
> will happen next year..).  
Fine. I'll be keeping my locally-modified version of serveez around
anyway, but it would be nice to have this stuff in CVS when I do a
first release of my DistWork P2P 'grid' (which will not be too soon,

> I do have some pending changes here myself and
> also will supply some mutex functionality as discussed in previous mails.
IIRC, your interface did access the muteces via names (const char
*). I don't think this is a reasonble interface -- you'd end up doing
two mutex locks for each mutex_lock API call - one to lock the hash
table with the mutex names, and one for the real mutex. Moreover,
you'd have to take the penalty of hash-table lookups and inserts. IMO,
the wrapper layer should be as thin as possible - best would be just a
bunch of #defines.

> I'll also re-consider the dont-kick-socket-on-receive-buffer-overflow.
> This will possibly go into a socket flag.
Hmm, dont-kick-socket-on-receive-buffer-overflow is not what I
intended (and already adapted svz_check_sockets_poll() for). My idea
is not to select (or poll) receiving sockets for 'reading readyness'
if their receive buffer is full (and they aren't listening sockets).

I have attached a patch with my current modifications of
svz_check_sockets_poll() - this should make my intention clear. One
could discuss if this should be default behavior, but IMO its a
reasonable solution that avoids receive buffer overflows completly.

> Before doing so we yet need to wait for the 'history' file issue in CVS
> being solved...

Regards, Andy
Andreas Rottmann         | address@hidden        | address@hidden | 
address@hidden | GnuPG Key:
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

reply via email to

[Prev in Thread] Current Thread [Next in Thread]