Re: change of socketport constructor

[klaus triendl]

well, before i make the patch i wanna address another issue:
before waiting for events in run(), the socketservice recalculates the port 
timers, eventually calls Port::expired() (and tries again in this case):

----
while(port)
{
        onCallback(port);
        //find out and set events to listen to
        ...
                
retry:
        expires = port->getTimer();
        if(expires > 0)
                if(expires < timer)
                        timer = expires;
        // if we expire, get new scheduling now
        if(!expires)
        {
                port->endTimer();
                port->expired();
                goto retry;
        }
        port = port->next;
}
----

what about self-deleting socketports? somewhen it has to be destroyed and freed 
(because e.g. i chose to close the port if the timer has expired). the deletion 
would happen in expired(); but in this case the port object is not valid 
anymore, port->getTimer() fails and port->next also (tested).
furthermore, if the port is deleted, no event listening has to take place.
we have to know somehow from expired() whether the port was deleted.


regards
klaus






On Sun, 13 Apr 2003 14:06:23 +0200
Dimitar Dimitrov <address@hidden> wrote:

> Hi,
> 
> What you mention is correct. The situation is even worse. The socketservice 
> thread can call the destructor of your socketport class before the 
> constructor of the object has finished.  I tried to mention this some time 
> ago, but it seems nobody noticed. And it is not only Win32 issue, looks more 
> like design problem. 
> 
> I'll be very interested in your patch.
> 
> Regards,
> Dimitar