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

[Andreas Rottmann]

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,
anyway)...

> 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...
> 
OK. 

Regards, Andy
-- 
Andreas Rottmann         | address@hidden        | address@hidden | 
address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62