Re: Blocking of multiple writers using the same event_system

After some further investigation I found it to work as intended, that 
is, multiple multiplex_controllers works independently of each other. 
The reason for the blocking was due to Sink_1 using a blocking call to 
Sink_2, causing Sink_1 also to block :-(

Hans Ole Rafaelsen wrote:
> Hi!
>
> I have an application that have 3 Uq_engines.multiplex_controllers sharing
> the same Unixqueue.event_system.  One controller is reading from a socket
> and forwarding the packets using the two other controllers that writes to
> their sockets. All are TCP connections.
>
>                                   Stream
>          Stream               |---------------> Sink_1
> Source -----------> Application
>                               |---------------> Sink_2
>                                   Stream
>
> The controllers run independently of each other. That is, the reader will
> read the next packet, start the two writers and request for a new packet,
> not waiting for the writers to finish. In order to prevent the writers from
> being overrun, their state is checked before each write, and if they are
> still writing, then the packet will be queue in the application until the
> writer finishes writing.
>
> The problem is that if I block (stop reading, but maintaining the
> connection) one of the receiver (sink_1) of the streams from the
> application, the other out stream also get blocked. From the receiving
> application (sink_2) it looks like it happens instantly, even though it goes
> some time before the other writer also start complaining that it is in
> write_state. The application is still receiving packets from the source. If
> sink_1 start reading packets again, the application "recovers" to it's
> normal state and continues processing packets.
>
> Is this expected behavior? In the documentation it says that there can only
> be one active writing on a multiplex_controller, but it states no limitation
> on the number of active writers for the event_system. Does the limitation
> also apply to the event_system? If so, what is the best suggestion for a
> workaround?
>
> Thanks,
>
> Hans Ole 
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/