Aaron, I'm getting compiler warnings from your latest changes:

serverchild.c: In function 'PerformChildTask':
serverchild.c:345: warning: passing argument 1 of
'child_reg_connected_client' discards qualifiers from pointer target type
serverchild.c:345: warning: passing argument 2 of
'child_reg_connected_client' discards qualifiers from pointer target type
pool.c: In function 'scoreboard_setup':
pool.c:124: warning: passing argument 1 of 'state_reset' discards
qualifiers from pointer target type
pool.c: In function 'scoreboard_release':
pool.c:189: warning: passing argument 1 of 'state_reset' discards
qualifiers from pointer target type

I'll fix them.


Aaron Stone wrote:
> On Fri, 2007-04-06 at 09:34 -0700, Aaron Stone wrote:
>> On Fri, 2007-04-06 at 15:26 +0200, Paul J Stevens wrote:
> 
>>> Most of that struct was simply stubbed as a todo. It would be nice
>> if we could
>>> track some key information per client:
>>>
>>> - total traffic send and recieved
>> We've have to take the return value number of bytes from every read and
>> write operation. Maybe there's a way to inquire on the socket itself
>> with some OS's? 
> 
> I haven't found anything yet. Any and all ideas welcome!
> 
> If we had wrappers around all of our output functions, we could just
> count the bytes as they went out. In some cases this isn't immediately
> possible, such as output generated from GMime.
> 
> [snip ideas about per-user, per-ip connection tracking]
> 
> I updated the code a bunch this morning, and I'm pretty happy with the
> results now:
> 
> localhost dbmail-2.2 # kill -USR1 `cat /var/run/dbmail-imapd.pid `;
> sleep 1 ; cat /var/run/dbmail-imapd.state | head
> 
> Scoreboard state: children [3/100], spares [1 (1 - 2)]
>    Child     PID  Status   Count           Client         User
> 
>        0   22704       0       0     
>        1   22672       1       1        localhost         test
>        2   22687       1       2        localhost    
>        3      -1     255       0       
>        4      -1     255       0          
> 
> I don't recommend beating the crap out of DBMail with SIGUSR1's all the
> time, but for a quick status report now and then, this should be a major
> improvement.
> 
> Aaron
> 
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> 


-- 
  ________________________________________________________________
  Paul Stevens                                      paul at nfg.nl
  NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Reply via email to