Re: [wxhaskell-users] Sigsev on Process example

[Daan L. <da...@cs...>]

Benedikt Grundmann wrote:

>Well it's a *critical* part of an application I'm currently writing together
>with a colleque (part of my bachelor thesis in computer science).  Implementation
>is still in it's infancy so I could switch to another programming language
>even though I *really* want to use haskell :-).  Do you know wether it is a
>wxhaskell or a wxWidgets or wxGTK Problem?  I'm willing to give it some more
>work / testing but not much as my time constraints to not permit that.
>  
>
Ok, first of all try to compile wxHaskell with an experimental 
wxWidgets, like 2.5.2  (I haven't tried 2.5.3 yet).
Secondly, if you have a nice debugger, you could look into the wxHaskell 
process code. I have just
done so, and couldn't find any glaring errors, but maybe you'll find the 
problem with the right mix of
trace statements :-)

How does it work: first, I create a Process object that runs 
asynchronously and redirects input/output.
(See WXCore/Process.hs) The process objects sends events to a parent 
which catches them. The
"OnInput" events are the important ones. To implement non-blocking IO, 
those event handlers
(See WXCore/Events.hs) create "InputSink" objects to deal with that. The 
"inputSink" objects are
implemented by me in C code  (See wxc/src/extra.cpp,  a bit of a mess 
here, but you'll find the relevant section :-)
The InputSink class derives from the wxThread class and starts a 
seperate thread that reads from the
input stream. While the thread is not destroyed, it reads from the 
stream. When something is read, it
creates a "InputEvent" that contains the data and "posts" it to the main 
GUI loop where it can be processed
by the main GUI/Haskell event thread. How does the event know which 
object should get the event? well,
it has a special "id" that identifies it. However, now that I think 
about it, I take the input stream pointer as the
value which seems kind of wrong -- maybe it should be the "id" of the 
parent object for the process, or even
the id from the process object -- try to play with that a bit.

Well, I hope this helps a bit with debugging -- I couldn't reproduce 
your problems (yet), but I'll try later
this week.

-- Daan.

>Thanks again for your work,
>
>Cheers,
>
>Bene
>
>  
>