Re: [phodav PATCH 4/4] spice-webdavd: Automount shared folder on Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> 
> Yes, so you could start it after the service is actually started and the
> virtio port is opened, no? (repeating myself here)
> 
> Ah you mean socket_service? I thought you meant the windos service.
> Yeah I can move it just above start_mux_read (mux_istream);
> 

or after (everything needs to be setup before you probe the service)

> 
> > 
> > I can imagine it may block because WNetAddConnection2 function call is sync
> > and will probe the service. But if it's blocking then it will not be able
> > to
> > handle its communication work.
> > 
> > Why not wrap WNetAddConnection2 in a GSimplaAsyncThread and run it once the
> > client connection is established?
> > 
> > Well that's the problem. I don't know when the client is connected, because
> > there is no signal/callback,
> > anything that would notify me, that the client connected. The only way I
> > know, that the client is connected,
> > is that the service stops looping, because it blocked in read_thread (this
> > was happening before my patches also).
> > 
> 
> > When it blocks, I have no way to call anything, that would map the drive,
> > or
> > notify something to map the drive.
> 
> read_async is.. async! the thread is a helper, the mainloop is free for other
> events/task.
> 
> But read_async is not the issue, read_thread is.
> g_input_stream_read_all() is not async, so it blocks when there are no data.

yes, that's why it's in a thread

> It only receives data, after:
> 1. client connects
> 2. enables sharing
> 3. maps the drive
> 
> 
> 
> > That's why the only way was to start something before the read blocked,
> > wait
> > for a few seconds, and if nothing
> > told it otherwise, it would map the drive. If the read didn't block, it
> > would
> > somehow notify this something,
> > that the client is not actually connected, and not to map the drive.
> > 
> > I spent a few weeks trying to implement something using already defined
> > signals, g_poll, even windows specific
> > polling/async reading, but nothing worked.
> 
> Check if the mainloop is working properly using a timer, it should be fine.
> Then we can realize it's blocking when you actuall call WNetAddConnection2,
> and then you realize it's the reason you need a thread.
> 
> The mainloop should work fine, the only think that's blocked is the
> read_thread
> (talking about a function called read_thread here)

I don't see the problem with the thread helper.

> 
> I can try something else using mainloop, but just so we understand each
> other,
> I still need another thread. It doesn't matter, if it's mainloop, or mine
> thread,
> but it HAS to be a different thread then the one where read_thread() is
> working.
> We agree on that right?

read_thread is already a seperate thread, you have a free thead with the main loop.

It's not about agreeing, it's about understanding and explaining why it needs an extra thread (and timers).

You can mostly ignore the read_thread and just think of the async calls from the main loop.

> 
> 
> 
> > 
> > The bottom line is that even when it is usually better to use something
> > more
> > high level then a thread,
> > I think it's safe to use a thread here, and using more high level stuff
> > wouldn't bring any advantage.
> 
> My bottom line is: don't use thread if you don't need them
> 
> > When I tried implementing something other then a thread, the only thing
> > that
> > brought was a headache,
> > because they refused to work at all.
> 
> That's a good sign that there is something you didn't solve properly.
> 
> Yes, I'm aware of that. But since thread worked properly, I had no issue with
> using it.
> 
> 
> 
> 
> > 
> > 
> > 
> > > As for why this has to be in a different thread, then read_thread, is
> > > because
> > > if I call map_drive before
> > > read actually blocks, it returns error, as if it's not connected. I think
> > > this is because when we try to map
> > > the drive, client sends a message to the guest, and the read has to be
> > > ready
> > > to receive it, which in turn
> > > lets the map_drive to actually map the drive.
> > > 
> > > I tryed using every possible way I could think of, even windows specific
> > > polling, but I couldn't make
> > > anything work, except just plain spawning another thread.
> > > 
> > > Lukas Venhoda
> > > 
> > > _______________________________________________
> > > Spice-devel mailing list
> > > Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > 
> > 
> > Lukas Venhoda
> > 
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > 
> 
> Lukas
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]