"Rolf" <rolf.ebert_nospam_@gmx.net> wrote in message 
news:1138659171.491931.322480@g49g2000cwa.googlegroups.com...
[snip]
>In a stripped down version I can succesfully connect to the server
>(using GNAT.Sockets) and either read the sensor data *or* write actor
>data. The program is currently split in two tasks. One tasks contains
>the application code and the actor communication (using
>type_id'output(channel)). The second tasks gets started during program
>initialisation. It reads the data from the socket via
>type_id'input(channel) and provides the data to the application through
>a protected object.
>
>The problem that I face is that the second task seems to starve the
>first one. As soon as it is active, the application does not generate
>debug output anymore.
>
>Some background info: gcc-3.4.4 on Windows XP. Java for the world
>simulation. The simulator sends about 20 packages � 11bytes every
>100ms. The application sends typically 2-3 packages per second. I have
>delay statements in both main loops (varied between 0.0 and 0.2
>seconds).
>
>My questions:
> - is that a reasonable tasking approach?
> - I don't know much about sockets (or better I don't remember much).
>Does a waiting read (in the second task) block a write in the first
>task?
> - how can I interrupt the waiting read task to force activity in the
>main task?
> - what other hints can you give me?
>
>
>TIA
>   Rolf

Your approach sounds reasonable to me.
I wrote my own wrappers for Win32 sockets API before GNAT.Sockets
was born,  so I can't say much about their behavior... but,  using the
Win32 API, I have been able to have one task reading a socket and another
task writing the same socket using blocking TCP/IP sockets with no
issues of reads causing writes to block or vise-versa.

I have seen the type of problem you describe with serial I/O on windows.
With serial I/O you have to open the device file with an OVERLAPPED
attirbute or one task pending on a read will cause a write to block  As I
mentioned earlier, I'm not familiar with the GNAT.Sockets implementation
so it is entirely possible that you are seeing the same behavior because of
the socket implementation.

Steve
(The Duck)