wine-devel

wine-devel@winehq.org

84463 discussions

Re: fix for Lawson's CLOCAL problem
by Alexandre Julliard 21 Aug '01

21 Aug '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > Hmmm. i'm not exactly sure about this. i don't think the server ever > blocked on serial port reads or opens... i think the reason Lawson had > problems was that the client thread was blocking in the overlapped > read code. (FILE_AsyncReadService in files/file.c) I don't know if this was Lawson problem, but open() can potentially block on a serial port, and we cannot have that in the server; so your change to set O_NONBLOCK is good, but it shouldn't depend on FILE_FLAG_OVERLAPPED. > If we use non-blocking fds unconditionally, a non overlapped ReadFile > may result in a busy loop in the client thread. Sure, you need to reset the O_NONBLOCK flag to do blocking reads. > Additionally, overlapped read (and write) requests should fail unless > the handle is opened with FILE_FLAG_OVERLAPPED. There are programs > that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on > this list). This is another reason to propagate CreateFile's > attributes parameter into the wineserver. Of course, I have no problem with that. The create_file request takes attributes, so create_serial can do the same (it would be better if create_serial were done inside create_file, but that's another story...) > Another question: do you think it would be possible to implement a > "write memory" message from the wineserver to the client? This message > would be carried over wait_fd and would be received by the client > asynchronously in wait_reply(). The message would contain a length, > address and data to be written. If this is possible, i could move > async i/o back into the server, keep it efficient and perhaps > implement CancelIo properly... But that would require multiple copies of the data (and many context switches for large reads); that wouldn't be very efficient. I think the current approach is much better. What is the problem with doing CancelIo? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winsock stuff
by Daniel Walker 21 Aug '01

21 Aug '01

This seems to work.. Daniel Walker --- server/sock.c 2001/05/14 20:09:39 1.18 +++ server/sock.c 2001/08/21 01:31:04 @@ -113,9 +113,14 @@ { struct sock *sock = (struct sock *)obj; unsigned int emask; + char rBuf; assert( sock->obj.ops == &sock_ops ); if (debug_level) fprintf(stderr, "socket %d select event: %x\n", sock->obj.fd, event); + + if (event == POLLIN && !recvfrom(sock->obj.fd, &rBuf, sizeof(rBuf), MSG_PEEK, NULL, NULL)) + event = POLLHUP; + if (sock->state & WS_FD_CONNECT) { /* connecting */

1 0

Re: fix for Lawson's CLOCAL problem
by Mike McCormack 21 Aug '01

21 Aug '01

Hi Alexandre, Hmmm. i'm not exactly sure about this. i don't think the server ever blocked on serial port reads or opens... i think the reason Lawson had problems was that the client thread was blocking in the overlapped read code. (FILE_AsyncReadService in files/file.c) If we use non-blocking fds unconditionally, a non overlapped ReadFile may result in a busy loop in the client thread. Additionally, overlapped read (and write) requests should fail unless the handle is opened with FILE_FLAG_OVERLAPPED. There are programs that depend on that behaviour (as reported by Eric Kohl, 3 Feb 2001 on this list). This is another reason to propagate CreateFile's attributes parameter into the wineserver. Another question: do you think it would be possible to implement a "write memory" message from the wineserver to the client? This message would be carried over wait_fd and would be received by the client asynchronously in wait_reply(). The message would contain a length, address and data to be written. If this is possible, i could move async i/o back into the server, keep it efficient and perhaps implement CancelIo properly... Mike > The open on the server side must always be non-blocking, we cannot > have the server block on anything. If there are cases where we need to > block on open, it will have to be done on the client side. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: winsock stuff
by Alexandre Julliard 21 Aug '01

21 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > How is it unreliable? Why is MSG_PEEK more reliable? I'm not opposed to > using MSG_PEEK , just curios.. FIONREAD is unreliable because you cannot distinguish between an EOF condition and an empty receive buffer. recvmsg(MSG_PEEK) is supposed to return 0 on EOF, and EWOULDBLOCK on empty buffer, so you can determine the real status. > Another issue is why doesn't poll() give > us a POLLHUP? That would be ideal, get poll() to work the way we need it > too. As I understand it poll() returns POLLHUP only when both directions of the socket have been closed; but if you shutdown() only the read or write side, you don't get POLLHUP so that you can continue using poll() for the other direction. This has apparently been changed between kernels 2.2 and 2.4; in 2.2 POLLHUP is returned as soon as the read side of the socket has been closed. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winsock stuff
by Alexandre Julliard 21 Aug '01

21 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > To improve on this patch we could only do the FIONREAD if the sock is > in a non-blocking state. That's the only time that doing the FIONREAD > would be an advantage. Also we wouldn't need to worry about screwing up > blocking sockets. Even further, we could only do the FIONREAD if socket > is non-blocking and looking for an FD_CLOSE event. Using FIONREAD is simply not an option, it cannot be made reliable. A possibility to detect EOF could be a recvmsg with MSG_PEEK flag, though you should probably verify first that it behaves as expected. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard 20 Aug '01

20 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > I noticed that WSAEnumNetworkEvents() was returning all events that had > occurred and not just the events that had been selected with > WSAEventsSelect(). Win98 will trigger the event object for all events > but WSAEnumNetworkEvents() (in win98) would return zero if the event > hadn't been selected. I was trying to gain compatibility with win98. I'd suggest doing the masking in WSAEnumNetworkEvents then. > An FD_READ event with a zero buffer would mean that the other side > closed the connection so it would be equivalent to a POLLHUP from poll() > .. I didn't find an occasion when poll() actually returned POLLHUP when > the socket closed, on Linux anyway. The application that I was testing > got confused when recv() returned zero. Even though recv() can legally > return zero, I think non-blocking applications are going to be looking > for FD_CLOSE events as opposed to recv() returning zero. But FIONREAD can return 0 bytes even when the socket isn't closed (for instance if another thread got the data first). You can only determine that it was really closed when you do the actual read. So I don't really see how we can avoid having recv() return zero; well maybe we can make it return EWOULDBLOCK and tell the server the connection is closed, but I'm not sure it's any better. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winsock stuff
by Alexandre Julliard 20 Aug '01

20 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > -changed get_socket_event() so it only returns events that > the application is looking for. > -Changed sock_poll_event() to interpret a POLLIN event with > zero bytes waiting to be read as a POLLHUP. This doesn't look really right to me. Could you please explain a bit more what it is supposed to fix? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Refcounting in SelectObject
by Alexandre Julliard 20 Aug '01

20 Aug '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Appended code tries to clean up better by: > - Remembering an unsuccessfull DeleteObject by adding 0x8000 to the Refcount > - Call DeleteObject in SelectObject when the RefCount of the released handle > is 0x8000 > - Decrementing the RefCount when a hBitmap is still selected into a DC when > DeleteDC is called for that DC > - Call DeleteObject in DeleteDC when RefCount is 0x8000 > > For some applications I tested, I always saw the delayed DeleteObject done > after the refused DeleteObject in the first place. Is this approach better? Yes, looks good. Though we can probably safely use the dwCount field in GDIOBJHDR since it is not used for anything useful right now, instead of adding new fields. I've changed that and applied the patch. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: fix for Lawson's CLOCAL problem
by Alexandre Julliard 20 Aug '01

20 Aug '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > Open serial ports with O_NONBLOCK if FILE_FLAG_OVERLAPPED is > specified. The open on the server side must always be non-blocking, we cannot have the server block on anything. If there are cases where we need to block on open, it will have to be done on the client side. -- Alexandre Julliard julliard(a)winehq.com

1 0

-clocal and the wineserver
by lawson_whitney＠juno.com 19 Aug '01

19 Aug '01

Good day! Any time clocal falls out of the modem's termios (say I use cu -l on it) the wineserver hangs trying to open it, or at least the app hangs, and I haven't found a way to kill it without killing the wineserver. Both 16 and 32 bit versions of juno are affected. I haven't really investigated it very thouroughly, but I wasted a lot of time restoring backup versions of the app and wine. Should I look into mickey-mousing the open to avoid the problem, or - is it really a wineserver problem which I am probably not even marginally competent to muck with? I'd be glad to make traces or winedbg output, but it seems the problem should be easy to duplicate. Hmmm, setting clocal back on from another terminal unhangs the app. That is neater than killing the wineserver, I guess. terminal.exe from wfw 3.11 behaves similarly, with an extra twist: it hangs on the Win16Mutex until somebody sets clocal (well, I guess carrier detect would work, too). [whit@giftie user0001]$ wine terminal.exe err:ntdll:RtlpWaitForCriticalSection section 0x400fad6c "syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) fs=008f fixme:pthread_kill_other_threads_np Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default xterm: unable to open font "vga", trying "fixed".... Failed to open input method passed master doesn't match slave name passed master doesn't match slave name [whit@giftie user0001]$ Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel