Issue with _dbus_write_socket on windows

[Ralf Habacker]

Havoc Pennington schrieb:
> Christian Ehrlicher wrote:
>> Havoc Pennington schrieb:
>>>
>>> Christian Ehrlicher wrote:
>>>> Thx, for the hints. Now the daemon is started on demand and adress is
>>>> read from shared memory.
>>> How did you go about making it per-user instead of per-machine?
>>>
>> Currently this is not supported, but I think it should be possible by
>> adding a userid or something else to the shm name.
>
> My .02, I don't think this is a "would be nice" feature - it's pretty
> essential to dbus working right.
>
>> But the bigger
>> problem is - how can I avoid using the same port twice? And how can I
>> react when the port is already in use?
>>
>
> I already mentioned that in another mail - you may need to write a new
> DBusTransport variant that uses named pipes or Windows messages. That
> would be cleaner and faster anyway. 
Christian  Ehrlicher tried to implement  named pipes and recognized that
there are major problems causes by the way named pipes are implemented
in windows.
Dbus transport layers are build up in all the same manner:

1. init connection on server side
2. wait for client connections
3. wait for data to read (_dbus_poll() using a system provided event
waiting function like select() or poll()
4. read/write data
5. goto 3 in case client does not close connection

On client side
1. init connection to server
2. write date if avaiable
3. wait for data to read (_dbus_poll() using a system provided event
waiting function like select() or poll()
4. read
5. goto 2 if more data
6.  close connection

Named pipes does not have a wait function mentioned in 3. There is only
a PeekNamedPipe function, which returns immediatly regardless if there
is data or not, which requires to implement a time consuming idle loop
in the application  itself.  There is a way to define completion
functions, but they are called after ReadFile(), which does not fit in
current dbus calling structure.  :-(  
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipes.asp
for more information
> Or figure out how to define the TCP stuff, I'm not sure how the X
> server defines it if there are multiple X servers, but it could work
> in the same way perhaps.
this works now. See in windbus svn.

Ralf