> 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
This archive was generated by hypermail 2b29 : Wed May 24 2000 - 10:12:15 MET DST