On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote:
luke, you are a star: thank you for helping out with this.
just for people's information (in case it's not been mentioned here - i must admit i forgot to notify opendce@opengroup.org!)
about 6-8 months ago i did a coding-spree on freedce, with a view to achieving two, maybe three, major things:
1) porting to win32 (if you use pthreads-win32)
2) using posix final draft (7?) threads not posix draft 4.
3) proving to the people on wine and reactos that they have a hell of a lot of work to do (measured in man-decades) by not using the open group's DCE/RPC reference implementation.
here's the gotchas that i encountered, and had to give up:
- udp worked, but tcp did not
- reactos had some problems at the time with the code behind ipconfig.exe (NetTransportEnum i think it was)
- pthreads-win32 was too strictly posix compliant (!) and there is a cancellation exception or something which makes it fail in the dcethreads exception library tests, where linux does not fail (!)
maybe this is related to what lukeh is talking about. *shrug*.
anyway, the upshot is that freedce/latest-cvs also doesn't work on TCP, and thank you so much people for helping track down why.
it's only been ten years so far: hopefully some time within the next decade, freedce will be used for some real MSRPC-related free software projects.
l
In rpc__cn_network_receiver(), rpc__socket_close() is called without an exception handler in place. According to IEEE Std 1003.1 (2004), close() is a cancellation point, see:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
Given this, a receiver thread could receive a cancel whilst closing the socket, which will cause to entire program to abort. (We have seen this occur when the RPC server is under load.)
A suggested fix is to move the call to rpc__socket_close() inside the TRY/CATCH_ALL block that removes any pending cancels.
It seems like the real fix is to disable cancellation within rpc__socket_close(), because in other places the OSF code appears to assume that this is not a cancellation point.
Ditto for open(), socket(), etc (but not I/O routines that may block).
I should note that the Linux dcethreads library does actually disable cancellation for these calls, however in our own DCE thread library we opted not to override any system calls to avoid changing semantics when used by non-DCE code.
-- Luke
--