Re: change of socketport constructor

[Dimitar Dimitrov]

On Tuesday 15 April 2003 00:15, klaus triendl wrote:
[cut]
> 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.
[cut]

This comes obvious from one of the examples, doesn't it? The idea of 
expired(), as far as I got it, apart from simply notifying about the 
expiration is that one can reset the timer and that's why it should be 
checked again in that "goto" loop. I don't know... may be a bool result will 
be good enough. expired() returns true and that's it, it really expired.. end 
of story... we don't "goto retry" again.
BTW, isn't it better if expired() is moved to TimePort interface. After all it 
deals with time issues. 

Some other remarks. They concern more Win32 implementation with which I played 
some time ago, so I may have forgotten something.  

For example something that becomes obvious very fast is the difference in 
semantic of the SocketService::Sync class and the pipe used in non-Win32 
implementation. The thing is that SocketService::Sync object has a place to 
hold only one byte. What happens at the end of ~SocketService(). If there is 
no thread anymore (after update(0) and terminate() the thread should be gone) 
to read the flag from the Sync instance and to release the semaphore then the 
attempt to delete the next port object

while(first)
        delete first;

will block because destructor of the port tries to call update() and that one 
blocks on the semaphore. Not to mention that the Sync object is already 
gone!!! BTW, the non-Win32 implementation doesn't look more correct, but 
there at least I can write to the pipe and my thread will not block. It also 
will not hurt if the pipe descriptors are closed at the end.

Also in connection with this I think (but I can be wrong) that 
SocketService::Sync::getFlag() should realease the semaphore if the flag is 0 
as far as 0 is a valid value.

Another issue if I remember correctly was with calculating the time in Win32 
implementation of TimePort. The GetTickCount() will wrap around after some 
period of time which is quite long, but in some cases even very long is not 
long enough. All depends on the view point. I don't remember the period 
exactly, but it was in terms of days which is quite different from what 
gettimeofday() gives.

OK. It become a long e-mail...

Best regards,
Dimitar