Re: [Evolution-hackers] Closing a NSS connection

2007-12-15 Thread Matthew Barnes
On Sat, 2007-12-15 at 10:02 -0500, Matthew Barnes wrote:
 On Sat, 2007-12-15 at 13:53 +0100, Philip Van Hoof wrote:
  I don't think just doing a PR_Close is sufficient. I think you need to
  do a PR_Shutdown too. GMail's IMAP server, for example, after pressing
  really often connect-disconnect, will otherwise ban you from authent-
  icating for a few minutes.
  
  I think this patch can be 1:1 applied to upstream Camel.
  
  http://tinymail.org/trac/tinymail/changeset/3135

Philip, I see PR_Close() being used on its own in two other places in
that file, particularly stream_close() but also during error cleanup in
socket_connect().  Do either of these locations also need to call
PR_Shutdown()?

I'm thinking stream_close() definitely does but maybe not the error
cleanup in socket_connect() since a connection has not yet fully been
established.

Matthew Barnes

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Closing a NSS connection

2007-12-15 Thread Srinivasa Ragavan
On Sat, 2007-12-15 at 10:02 -0500, Matthew Barnes wrote:
 On Sat, 2007-12-15 at 13:53 +0100, Philip Van Hoof wrote:
  I don't think just doing a PR_Close is sufficient. I think you need to
  do a PR_Shutdown too. GMail's IMAP server, for example, after pressing
  really often connect-disconnect, will otherwise ban you from authent-
  icating for a few minutes.
  
  I think this patch can be 1:1 applied to upstream Camel.
  
  http://tinymail.org/trac/tinymail/changeset/3135
 
 Yeah, I think Philip's right.  The NSPR API documentation for PR_Close
 [1] and PR_Shutdown [2] is not very helpful, but I did manage to find
 this:
 
 Once the exchange has been accomplished, the transport is shut
 down with a call to PR_Shutdown, as shown in line 106. This
 operation effectively disables any further use of the file
 descriptor for anything other than closing it. The call to
 PR_Shutdown does not, however, eliminate the need to close the
 descriptor. The call to PR_Close is in main() (the creator the
 the TCP stream) and is required to reclaim the resources used by
 the runtime to support the connection.  [3]
 
 So I'll commit this for 2.21.4.
Thanks Matt and Philip.

-Srini
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Closing a NSS connection

2007-12-15 Thread Matthew Barnes
  Philip, I see PR_Close() being used on its own in two other places in
  that file, particularly stream_close() but also during error cleanup in
  socket_connect().  Do either of these locations also need to call
  PR_Shutdown()?
 
 Yes, I fixed the other locations in Camel-lite too. Sorry for not
 mentioning that followup of that patch (you can go a few revisions
 higher in Tinymail to see the other PR_Shutdown-s).
 
  I'm thinking stream_close() definitely does but maybe not the error
  cleanup in socket_connect() since a connection has not yet fully been
  established.
 
 I just added them to all. If you find a PR_Close where it was not
 needed, let me know.

Looks like there's a couple more PR_Close() calls in e_msgport_destroy()
(libedataserver/e-msgport.c).  I'm assuming these need shutdown too?

Matthew Barnes

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Closing a NSS connection

2007-12-15 Thread Philip Van Hoof

On Sat, 2007-12-15 at 11:36 -0500, Matthew Barnes wrote:

 Looks like there's a couple more PR_Close() calls in e_msgport_destroy()
 (libedataserver/e-msgport.c).  I'm assuming these need shutdown too?

No, as far as I know those are named pipes. Not socket filedescriptors.

But feel free to verify my claims, I don't know all such details of
Camel by heart ;)


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be




___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers