Issue with _dbus_write_socket on windows

[Christian Ehrlicher]

Timothy Vismor schrieb:
> On 11/17/06, Havoc Pennington <hp at redhat.com> wrote:
>>
>> Ralf Habacker wrote:
>> > Havoc Pennington schrieb:
>> >> I don't know exactly, since I don't know how this works on Windows.
>> >> What is the "fd" you pass to the daemon's --print-addr-fd function? Is
>> >> it a pipe or a socket or what is it? On UNIX autolaunch does a
>> >> fork/exec, what does it do on Windows?
>>
>> btw what is the answer here? (where do you guys have the windows code
>> btw, can we look at the work in progress?)
>>
>> > We are thinking to store the recently used dbus address in the
>> registry,
>> > which allows the autolaunch code to detect a running dbus-daemon 
>> and to
>> > be able to connect to it.
>>
>> Maybe Windows should only have "autolaunch" and never start the daemon
>> on login; unlike unix there might be a more reliable way to implement
>> autolaunch. How does the registry solution work in terms of locking,
>> i.e. say two buses start up simultaneously in the same session, one
>> should exit and not be used. Is there a way to lock a registry entry or
>> something that allows that to work?
>>
>> For the mugshot client we did single instance COM object with
>> RegisterActiveObject() - that seems like one option. I'm not sure how it
>> works if the user logs in multiple times (is that even possible?) though.
>>
>> Havoc
> 
> 
> A common way to guarantee a unique instance of a Windows application
> is to use a well known mutex name. A simple example is:
> 
Thx, for the hints. Now the daemon is started on demand and adress is
read from shared memory.

Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061119/a39e2aa1/signature.pgp