Bug in FXMessageChannel on WINDOWS

[Axel Schmidt]

I have switched to FOX 1.7.15 after using 1.6.

On FOX-1.6 I have used a FXGUISignal to signal a window (which displays data) that data has arrived from a worker thread recieving data asynchroneously via TCP sockets . The new data is put into a data array before singalling. When the signal is received through the message loop I add the new data to a list box in the windows that display rthe data. This is working fine.

So, now I have replaced the FXGUISignal with a FXMessageChannel (just a single message without the data, the data is put into the thread safe data array as before). This is working in principle, but when the incoming data frequency is increased the programm runs in a stuck situation (not eben a dead lock, but something like that).

I have not a solution for this problem, but I think following happens:

The message() function of the FXDataChannel is called faster than the data is read (via onMessage()). Since the onMessage() function removes only a single message from the windows pipe, it can happen that a additional message keeps in the pipe buffer. So, the number of push/pop actions are not matching after a while. If you are really fast, then the pipe buffer is full after a while. When this happens the WriteFile-Command is blocked until enough memory is present again. But this will never happen, since the SetEvent() is called after the WriteFile() call.

I have though to check if there is data left in the pipe buffer (via PeekNamedPipe), but this slows the system really down. Maybe using a CSemaphore instead of the CEvent is the solution. I think you use WaitForMultipleObject somewhere in the FXApp the get the signalled events.

Can you help me? The use of the "old" FXGUISignal is not longer supported, I think.  

[Jeroen van der Zijp]

On Thursday 28 August 2008, you wrote:

>
> I have switched to FOX 1.7.15 after using 1.6.
>
> On FOX-1.6 I have used a FXGUISignal to signal a window (which displays
> data) that data has arrived from a worker thread recieving data
> asynchroneously via TCP sockets . The new data is put into a data array
> before singalling. When the signal is received through the message loop I
> add the new data to a list box in the windows that display rthe data. This
> is working fine.
>
> So, now I have replaced the FXGUISignal with a FXMessageChannel (just a
> single message without the data, the data is put into the thread safe data
> array as before). This is working in principle, but when the incoming data
> frequency is increased the programm runs in a stuck situation (not eben a
> dead lock, but something like that).
>
> I have not a solution for this problem, but I think following happens:
>
> The message() function of the FXDataChannel is called faster than the data
> is read (via onMessage()). Since the onMessage() function removes only a
> single message from the windows pipe, it can happen that a additional
> message keeps in the pipe buffer. So, the number of push/pop actions are not
> matching after a while. If you are really fast, then the pipe buffer is full
> after a while. When this happens the WriteFile-Command is blocked until
> enough memory is present again. But this will never happen, since the
> SetEvent() is called after the WriteFile() call.
>
> I have though to check if there is data left in the pipe buffer (via
> PeekNamedPipe), but this slows the system really down. Maybe using a
> CSemaphore instead of the CEvent is the solution. I think you use
> WaitForMultipleObject somewhere in the FXApp the get the signalled events.
>
> Can you help me? The use of the "old" FXGUISignal is not longer supported, I
> think.  
>

The current implementation of FXMessageChannel still uses an Event object under
Windows.  I suspect what you're seeing is that since the Event is edge-sensitive,
causing SetEvent to have no effect unless FXApp's MsgWaitForMultipleObjects happens
to be waiting fot the Event.  If FXApp is already in the callback, then pulsing
Event using SetEvent has no effect and then next time we're back into MsgWaitForMultipleObjects
we just fall asleep instead of handling the input from the pipe.

I'm open to suggestions.  Note, the easy answers are probably not the correct ones,
in that they're not safe.

Perhaps try this [I'd appreciate any feedback on this]:

        1) Pass true for the second argument to CreateEvent in FXMessageChannel::FXMessageChannel

        2) Call ResetEvent(h[2]) before calling the callback to the target (around line
           130 in FXMessageChannel.cpp.



        Regards,

                        - Jeroen


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Axel Schmidt]

>I'm open to suggestions.  Note, the easy answers are probably not the correct ones,
>in that they're not safe.
>
>Perhaps try this [I'd appreciate any feedback on this]:
>
> 1) Pass true for the second argument to CreateEvent in FXMessageChannel::FXMessageChannel
>
> 2) Call ResetEvent(h[2]) before calling the callback to the target (around line
>   130 in FXMessageChannel.cpp.
>
>
I think your suggestion will work, the system do not stuck, but it does not handle the mismatch of push/pop problem if the are more than a single setevent during the processing of the message() function.

I come to another solution using a semaphore instead of an event.
I have tested it already, seems to be working:

1) replace in constructor of FXMessageChannel (about line 113) ..
  if((h[2]=::CreateEvent(NULL,false,false,NULL))==NULL){ throw FXResourceException("unable to create
with ...
  if((h[2]=::CreateSemaphore(NULL,0,MAXMESSAGE/sizeof(FXMessage),NULL))==NULL){ throw FXResourceException("unable to create semaphore."); }

2) replace in message() (about line 162)
   ::SetEvent(h[2]);
with
   ::ReleaseSemaphore( h[2], 1, NULL);

summary:
Now the performance is as very well as before (this means we can process about  2 data message in a millisecond and display the data in a FXList control). INFO: We are monitoring CAN messages from a CAN bus which are sent from a tcp ip gateway to the pc.

The unix/linux version of the software is not tested anyway, so i do not know if there is a problem, too. If we make again the linux version, i will check. Maybe it isn't a problem there, I am not really a linux professional.

regards
Axel

[Jeroen van der Zijp]

On Friday 29 August 2008, Axel Schmidt wrote:

>
> >I'm open to suggestions.  Note, the easy answers are probably not the
> correct ones,
> >in that they're not safe.
> >
> >Perhaps try this [I'd appreciate any feedback on this]:
> >
> > 1) Pass true for the second argument to CreateEvent in
> FXMessageChannel::FXMessageChannel
> >
> > 2) Call ResetEvent(h[2]) before calling the callback to the target (around
> line
> >   130 in FXMessageChannel.cpp.
> >
> >
> I think your suggestion will work, the system do not stuck, but it does not
> handle the mismatch of push/pop problem if the are more than a single
> setevent during the processing of the message() function.
>
> I come to another solution using a semaphore instead of an event.
> I have tested it already, seems to be working:
>
> 1) replace in constructor of FXMessageChannel (about line 113) ..
>   if((h[2]=::CreateEvent(NULL,false,false,NULL))==NULL){ throw
> FXResourceException("unable to create
> with ...
>  
> if((h[2]=::CreateSemaphore(NULL,0,MAXMESSAGE/sizeof(FXMessage),NULL))==NULL){
> throw FXResourceException("unable to create semaphore."); }
>
> 2) replace in message() (about line 162)
>    ::SetEvent(h[2]);
> with
>    ::ReleaseSemaphore( h[2], 1, NULL);
>
> summary:
> Now the performance is as very well as before (this means we can process
> about  2 data message in a millisecond and display the data in a FXList
> control). INFO: We are monitoring CAN messages from a CAN bus which are sent
> from a tcp ip gateway to the pc.

This is interesting.  Should we not simply initialize the count to MAXINT
since we're not really counting the number of threads [after all, we know
there's only one].   This way, we can call ReleaseSemaphore [basically]
any number of times.  If message() gets called too often, the pipe buffer
will simply fill up and we'd be blocking in WriteFile() [this presumably
happens much sooner than reaching MAXINT, but possibly later than the
MAXMESSAGE/sizeof(FXMessage) since the kernel pipe-buffering is way bigger
than this].

I do like this approach and since it works well for you I'll update the
implementation to use a semaphore instead...
 
> The unix/linux version of the software is not tested anyway, so i do not
> know if there is a problem, too. If we make again the linux version, i will
> check. Maybe it isn't a problem there, I am not really a linux professional.

Linux has been tested and works just great.  I use this facility in my own code,
and AFAIK there are no issues on Linux.


        Regards,

                                - Jeroen


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Axel Schmidt]

>Should we not simply initialize the count to MAXINT
>since we're not really counting the number of threads [after all, we know
>there's only one].   This way, we can call ReleaseSemaphore [basically]
>any number of times.  If message() gets called too often, the pipe buffer
>will simply fill up and we'd be blocking in WriteFile() [this presumably
>happens much sooner than reaching MAXINT, but possibly later than the
>MAXMESSAGE/sizeof(FXMessage) since the kernel pipe-buffering is way bigger
>than this].

Of course you are right, I have coded nonsense, replace "MAXMESSAGE/sizeof(FXMessage)" with "LONG_MAX" or "MAXINT" something like this.

Axel

[Jeroen van der Zijp]

On Tuesday 02 September 2008, Axel Schmidt wrote:

>
> >Should we not simply initialize the count to MAXINT
> >since we're not really counting the number of threads [after all, we know
> >there's only one].   This way, we can call ReleaseSemaphore [basically]
> >any number of times.  If message() gets called too often, the pipe buffer
> >will simply fill up and we'd be blocking in WriteFile() [this presumably
> >happens much sooner than reaching MAXINT, but possibly later than the
> >MAXMESSAGE/sizeof(FXMessage) since the kernel pipe-buffering is way bigger
> >than this].
>
> Of course you are right, I have coded nonsense, replace
> "MAXMESSAGE/sizeof(FXMessage)" with "LONG_MAX" or "MAXINT" something like
> this.

Well, I think using a Semaphore was a great idea; the initial value of the
counter is only a very minor wrinkle.


       
                - Jeroen

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users