Re: Serious SocketService/SocketPort problems

[Federico Montesino Pouzols]

        Yes, this is a serious problem. I also do not know how to
avoid it without moving the call to attach (or some kind of signaling
or lock/unlock to notify SocketService) to the derived classes instead
of the base SocketPort.

        Any other idea?

On Thu, Nov 21, 2002 at 11:35:59AM +0100, Prochnow, Christian wrote:
> Hi List,
> 
> here comes a really serious problem related to SocketService and SocketPort:
> 
> SocketPort() takes a SocketService argument, when SocketPort is created, it 
> attaches itself to the given SocketService. Which seems to lead to 
> synchronisation problems. 
> I have a class (say MySocketPort) that is inherited from SocketPort (with 
> outbound constructor). So when i create the MySocketPort object in the 
> main-thread the SocketPort() base constructor registers itself with the 
> SocketService which is then started by SocketService::attach().
> 
> So when the SocketService-thread begins to run and immediatly tries to 
> dispatch a virtual call to MySocketPort - it will be dispatched to the 
> default implementation (SocketPort::connect()) cause the vtable of 
> MySocketPort is'nt fully setup.
> 
> This seems to be timing-related, cause under Linux this works fine - under 
> Windows XP it crashes (i think new started threads in XP are immediatly 
> executed and the creator-thread gets yield).
>  
> I have no idea how to solve this. Only solution would be that SocketPort() 
> does not attach itself when constructing ... instead MySocketPort should 
> attach itself to the SocketService. 
> 
> Thanks in advance,
> Christian
> 
> -- 
> Christian Prochnow
> Berliner Freiverkehr (Aktien) AG - Kurfürstendamm 117 - 10711 Berlin, Germany
> Fon: +49-30-89606409, Fax: +49-30-89021389 - EMail: address@hidden
> 
> 
> 
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp