[Kde-pim] Proposal for a solution for bug 77862

Thomas McGuire mcguire at kde.org
Mon May 24 21:13:42 BST 2010


Hi,

On Monday 24 May 2010 18:22:54 Guy Maurel wrote:
> On Thursday 20 May 2010 19:27:33 Thomas McGuire wrote:
>
> > There are two different kind of timeouts: The first one is the timeout
> > for waiting when reading or waiting to read from a socket. That is what
> > I talked about earlier.
> > The second timeout is the timeout until a KIO slave process gets killed.
> > When KIO slave processes are not used anymore, they are kept around for
> > some time
> 
> this is right.
> this is the one we have to kill because we cannot use it anymore.

(I assume with "this is the one", you're refering to the KIO slave process 
timeout)
Why do you think the KIO slave has to be killed? Since the socket connection 
seems to be the problem, disconnecting and then reconnecting should solve the 
problem. Making the socket timeout lower ensures the the slave does not get 
stuck and actually has the chance to disconnect, I assume.
What am I missing here?

> > I think the re-using the same slave after suspend/wakeup is no problem,
> > and therefore the slave reuse timeout can stay high.
> > The only thing we need to make sure is that the connection gets
> > disconnected and reconnects again on wakeup. As far as I can see in the
> > code, the slave will automatically close the connection if the response
> > timeout is triggered, right?
> 
> more!
> We have two cases.
> 1. the ethernet connection is coming again with the same IP-address

Is this the same connection then or was the socket closed in the meantime, and 
then a new socket with a new connection opened?

> 2. we get another connection with an new address.

In both cases, disconnecting the old connection and establishing a new 
connection should work, or should it not? I currently don't see why this 
should be related to the actual slave process and why you would need a new 
slave process to correctly make the connection.

> The problem is, we cannot (so far I can see) get information about our own
> IP-address. It would be very easy to take a decision.
> 
> In both cases, we have to make sure, that kmail is able to connect again.
> The (soft) way we are trying togother today is not sure enough. I have to
> investigate why: a new kio_imap is created, but the connection:
> app->job->slave doesn't work.

I don't follow you here, sorry. Why is a new kio_imap process created, and in 
which situation?

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100524/01f27a3b/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list