A while ago, I noticed that our setup program didn't work with cvs wine. Somebody said "Oh, that's because named pipes are broken." Since then, the setup program works again with cvs wine, but I'm still curious about the state of named pipes.
The simple sequence CreateNamedPipe CreateFile seems to work under Windows, but not under Wine. Does Wine for some reason require a ConnectNamedPipe between the two? A very simple test is attached.
(BTW, I've been looking at the wineserver named pipe code a bit. Shame it's not better commented... at least it's small, so the lack of comments isn't too awful.) - Dan
On Monday 17 February 2003 08:26 pm, Dan Kegel wrote:
A while ago, I noticed that our setup program didn't work with cvs wine. Somebody said "Oh, that's because named pipes are broken." Since then, the setup program works again with cvs wine, but I'm still curious about the state of named pipes.
The simple sequence CreateNamedPipe CreateFile seems to work under Windows, but not under Wine. Does Wine for some reason require a ConnectNamedPipe between the two? A very simple test is attached.
(BTW, I've been looking at the wineserver named pipe code a bit. Shame it's not better commented... at least it's small, so the lack of comments isn't too awful.)
- Dan
nice catch!
This explains some things I've been noticing lately ;) There have been race-conditions in RPC lately, my uncomitted "rpc testcase" patch exposes them. Maybe you've found code (or hardware?) to consistently expose the losing side of the race? Wish I had a dualie for stuff like this ;)
Will take a peek and see if anything jumps out at me (fat chance, I presume, but wth...)
Hmmm. I didn't think of that case when I wrote the code :(
It seems that we need to add code to create a pipe and wait for a server (ps_wait_connect) in server/named_pipe.c, line 349, and some more to connect a new pipe server to waiting clients at line 380.
If somebody wants to do it feel free, otherwise I'll turn out a patch sooner or later...
Mike
Gregory M. Turner wrote:
The simple sequence CreateNamedPipe CreateFile seems to work under Windows, but not under Wine.
nice catch!
This explains some things I've been noticing lately ;) There have been race-conditions in RPC lately, my uncomitted "rpc testcase" patch exposes them. Maybe you've found code (or hardware?) to consistently expose the losing side of the race? Wish I had a dualie for stuff like this ;)
Will take a peek and see if anything jumps out at me (fat chance, I presume, but wth...)
Mike McCormack wrote:
Hmmm. I didn't think of that case when I wrote the code :(
It seems that we need to add code to create a pipe and wait for a server (ps_wait_connect) in server/named_pipe.c, line 349, and some more to connect a new pipe server to waiting clients at line 380.
If somebody wants to do it feel free, otherwise I'll turn out a patch sooner or later...
Hrm. I'm trying to understand how the calling thread gets put to sleep on, say, a call to WaitNamedPipe. Can I buy a vowel? - Dan
Hi Dan,
I don't know if this is what you want to hear, but I'm rewriting the named pipe code to handle message mode and solve the problem you pointed out, so if you wait a while, I'll have lots of new code for you... though it's probably a good idea to fix the current code first so we have a something that works before I break it again.
To make a thread go to sleep, you pass in an event flag in your request, then wait on the event flag in the client after the server call returns.
Mike
Dan Kegel wrote:
Mike McCormack wrote:
Hmmm. I didn't think of that case when I wrote the code :(
It seems that we need to add code to create a pipe and wait for a server (ps_wait_connect) in server/named_pipe.c, line 349, and some more to connect a new pipe server to waiting clients at line 380.
If somebody wants to do it feel free, otherwise I'll turn out a patch sooner or later...
Hrm. I'm trying to understand how the calling thread gets put to sleep on, say, a call to WaitNamedPipe. Can I buy a vowel?
- Dan
Mike McCormack wrote:
I don't know if this is what you want to hear, but I'm rewriting the named pipe code to handle message mode and solve the problem you pointed out, so if you wait a while, I'll have lots of new code for you... though it's probably a good idea to fix the current code first so we have a something that works before I break it again.
That is totally what I want to hear. I'm adding stuff to the named pipe regression test; any requests?
To make a thread go to sleep, you pass in an event flag in your request, then wait on the event flag in the client after the server call returns.
Ah, so the sleeping part isn't visible in server. Thanks! - Dan
That is totally what I want to hear. I'm adding stuff to the named pipe regression test; any requests?
Hi Dan,
Well, I'm curious to know what happens when you: * put a pipe into message mode, then do partial reads. * do TransactNamedPipe, and there is already read data available in the pipe. * DisconnectNamedPipe on a pipe that still has messages in it * try reading from a pipe that is not connected (before and after connecting) * switch pipes between message mode and byte mode with data in the pipe
I'm still coding it, then it needs to be debugged, reworked, cut up into patches, etc, but I'll send you a something when it doesn't crash immediately :)
Mike
Mike McCormack wrote:
Well, I'm curious to know what happens when you:
- put a pipe into message mode, then do partial reads.
- do TransactNamedPipe, and there is already read data available in the pipe.
- DisconnectNamedPipe on a pipe that still has messages in it
- try reading from a pipe that is not connected (before and after
connecting)
- switch pipes between message mode and byte mode with data in the pipe
Er, looks like it'll be a while before I test those, but I do have a just-barely-nontrivial test; wine fails it in several ways. Attached for your testing pleasure. - Dan
I'll keep updating http://www.kegel.com/pipe.c as I add more to the named pipe test... - Dan
Mike McCormack wrote:
Well, I'm curious to know what happens when you: ...
- DisconnectNamedPipe on a pipe that still has messages in it
Win2K pro: In byte oriented pipes, the bytes are lost, it appears.
- try reading from a pipe that is not connected (before and after
connecting)
Win2K pro:
Before connecting, you get the error ERROR_PIPE_LISTENING. This can only happen on the server side before the client opens the pipe, I think.
After disconnecting, you get the error ERROR_PIPE_NOT_CONNECTED on both client and server.
Wine is *not* doing well here. It crashes on a couple of these tests, and the unit test framework *doesn't notice*. See http://www.kegel.com/pipe.c for my current test.
More to follow. - Dan
Hey Dan,
Great work! Some of this problems may be solved by implementing our own pipes rather than using unix pipes. We're going to get a bit of a slow down, but I don't think there's any alternative if we want things to work correctly :(
I'm starting to test my new code. After I remove all the stupid mistakes and obvious bugs, I'll send you something to have a look at.
Mike
Dan Kegel wrote:
Wine is *not* doing well here. It crashes on a couple of these tests, and the unit test framework *doesn't notice*. See http://www.kegel.com/pipe.c for my current test.
More to follow.
- Dan
Gregory M. Turner wrote:
On Monday 17 February 2003 08:26 pm, Dan Kegel wrote:
The simple sequence CreateNamedPipe CreateFile seems to work under Windows, but not under Wine. Does Wine for some reason require a ConnectNamedPipe between the two? ...
nice catch!
This explains some things I've been noticing lately ;) There have been race-conditions in RPC lately, my uncomitted "rpc testcase" patch exposes them. Maybe you've found code (or hardware?) to consistently expose the losing side of the race? Wish I had a dualie for stuff like this ;)
No need for a dual processor to magnify this bug! Just apply the attached patch, and I bet you'll get the race to trigger every time you do an installshield install. It shows up as the dialog box "Object not registered".
BTW I'm slowly adding to tests/pipe.c; I need to exercise a few more calls, then it'll be a handy little unit test for anyone fixing up the named pipe support. (Just don't forget to remove the todo_wine in the test, else it won't actually test anything.) - Dan