communication problems

communication problems

[David Chemouil]

Hi,


I'm currently writing kind of a middleware, but I face strange
behaviors. I've got a client C and a server S, both
(bytecode-)multithreaded. They communicate with TCP sockets. When C
connects to S, S sends (by marshalling it, with the Marshal.Closures
parameter) some data (actually an empty list) to C. On S' side it works.
But C fails when doing a 'from_marshal' with a Sys_blocked_io exception.
The doc says:

exception Sys_blocked_io

     A special case of Sys_error raised when no I/O is possible on a
non-blocking I/O channel. 

I find this strange because, as far as I know, TCP sockets are
*blocking" channels.

Anyway, the problem is that my program fails *sometimes*. Some other
times, it works very well. And when it fails, it happens that my xterm
goes nuts, and refuses any operation involving the network (such as a
rlogin).

Has anybody met that kind of behavior? How did you handle with it?

Regards,

dc


-- 
David Chemouil [mailto:chemouil@enseeiht.fr] [mobile: 06 84 16 26 65]

Laboratoire d'informatique et de mathématiques appliquées (IRIT-INPT)

Re: communication problems

[Xavier Leroy]

> I'm currently writing kind of a middleware, but I face strange
> behaviors. I've got a client C and a server S, both
> (bytecode-)multithreaded. They communicate with TCP sockets. When C
> connects to S, S sends (by marshalling it, with the Marshal.Closures
> parameter) some data (actually an empty list) to C. On S' side it works.
> But C fails when doing a 'from_marshal' with a Sys_blocked_io exception.
> The doc says:

Right.  The Marshal.{to,from}_channel functions do not work in
conjunction with bytecode threads.  For Marshal.to_channel, use the
following definition instead:

let marshal_to_channel oc v flags =
  output_string oc (Marshal.to_string v flags)

and use input_value instead of Marshal.from_channel.

>      A special case of Sys_error raised when no I/O is possible on a
> non-blocking I/O channel. 
> I find this strange because, as far as I know, TCP sockets are
> *blocking" channels.

With the bytecode threads library, all channels are put in
non-blocking mode and I/O operations are wrapped specially so that a
thread that blocks waiting for I/O doesn't block the whole program.
All I/O functions in Pervasives and ThreadUnix are thus wrapped,
but not those in the Marshal module.  Hence the problem you
encountered.

Avoiding this kind of problems was an important motivation for the
system-level thread library (systhreads) :-)

Hope this helps,

- Xavier Leroy