Re: MinGW RPC and thread problem

Gerd Stolpmann <[email protected]> Wed, 23 Jul 2008 03:20:55 +0200
Newsgroups gmane.comp.lang.ocaml.lib.net.devel
Message-ID <[email protected]>
Am Donnerstag, den 17.07.2008, 18:56 +0200 schrieb Hans Ole Rafaelsen:
> Hi
> 
> during porting some code from Linux to Windows I have found a couple
> of minor issues with the MinGW port of OCamlnet.

Well, I know some major issues, especially for using RPC. But one step
after the other.

> Issue 1:
> I'm trying to use the RPC modules.  This is the problem as far as I can 
> tell:
> Unix.connect call of RPC fails with that operation would block
> (Unix.EWOULDBLOCK) in
> Uq_engines.class direct_socket_connector()
> method connect connaddr ues =
> function setup_socket (around line 2291)
> 
> changing  
> ...
>       with
> -    Unix.Unix_error(Unix.EINPROGRESS,_,_) ->
> +      Unix.Unix_error(Unix.EINPROGRESS,_,_)
> +    |  Unix.Unix_error(Unix.EWOULDBLOCK,_,_) ->
>         (s,stype,false)
>     | error ->
>         (s,stype,false)
> ...

Thanks for pointing this out. This is documented by Microsoft

http://msdn.microsoft.com/en-us/library/ms737625(VS.85).aspx

It's a bit surprising because POSIX doesn't document EWOULDBLOCK as
error code for connect, but the solution to treat EWOULDBLOCK like
EINPROGRESS seems to be the solution of choice.

I've changed that in svn.

> This fixes the problem of connecting to a running server. However it
> does not give the same behavior as under Linux. Under Windows you
> don't get any exception that the call would fail. Under Linux you get
> connection refused for blocking socket config
> (Rpc_client.blocking_socket_config) and for non blocking it reports on
> the following receive, trowing Rpc_client.Message_lost. Under Windows
> this problem is simply ignored. If the RPC call is synchronous it will
> block (forever) and if asynchronous, it will just go through without
> reporting any problem, and never calling the callback handle. I don't
> know if it is possible to easily fix the last issue due to difference
> in Windows and Linux, but the first part need to be fixed in order to
> get RPC running under Windows.

Apparently, Windows reports connect errors differently than Linux. One
has to wait until the socket becomes writable or out-of-band data is
signaled. In the first case the socket is connected, and in the second
case there is an error condition. Ocamlnet hasn't watched for the
latter. I've also changed that.

The current svn version looks now a lot better. I was able to query
portmapper, so at least RPC clients seem to work.

> Issue 2:
> The event system seems to fail if compiled with thread support. It
> fails with:
> Fatal error: exception Sys_error("Mutex.unlock: error code 120")
> Raised at file "", line 0, characters 0-0
> I have not digged into this yet. But if you think that this is a bug
> (threads are supposed to be supported under Windows) then I can have a
> look into this.

Error code 120 is ERROR_CALL_NOT_IMPLEMENTED (see
http://msdn.microsoft.com/en-us/library/ms681381(VS.85).aspx). It's a
bit surprising, but I'm sure we can clear this up. There are bigger
issues.

The major problem is that there is no way to cancel a running
Unix.select (you need that if a different thread changes the conditions
you wait for). For Linux this is simple - just put a pipe into the
selected fdset, and write something into the pipe when you want to
interrupt Unix.select. Windows does not support to add anything other
than sockets to selectable fdset's, and there are no socketpairs that
behave like socket-ized pipes, so this solution does not work.

Anyway, I've started tackling this problem. In the svn version
(https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/) you find a
special data structure called "pollset" that abstracts Unix.select, in
module Netsys_pollset. The module Netsys_pollset_win32 has a special
Win32 implementation (allowing cancellation). There is a variant of
unixqueues that can take advantage of pollsets:
Unixqueue2.pollset_event_system.

It is basically working, but not extensively tested. Furthermore, the
multi-threading part is not yet done.

Gerd

> I have attached some sample code that demonstrated the two problems.
> 
> Thanks,
> 
> Hans Ole
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
[email protected]          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/