Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jun 1998 20:19:52 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        joelh@gnu.org
Cc:        tlambert@primenet.com, grog@lemis.com, jkh@time.cdrom.com, sue@welearn.com.au, pechter@shell.monmouth.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: VT100 (was: PCVT's death)
Message-ID:  <199806242019.NAA12612@usr04.primenet.com>
In-Reply-To: <199806241908.OAA03550@detlev.UUCP> from "Joel Ray Holveck" at Jun 24, 98 02:08:03 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >> (1) Don't resize or move the window, or access the menus, unless you
> >> don't expect to be receiving data during the operation.  The
> >> temptation is great to resize to full screen during the MOTD, but if
> >> data arrives while you're fiddling with this, then the telnet client
> >> will be put in a bad state.  (It looks like a ring queue gets out of
> >> sync, but I could be wrong.)
> >
> > Actually, the events are lost.
> 
> That's curious, since that would seem that you would lose characters.
> Instead, characters are sent at approximately the same speed, just
> lagging behind.  For example, in this failure mode, after running
> 'ls -l' you may be left with (as the last few lines):

The notification *event* that would have normally triggered the
dequeue of the Windows "event" (quoted because it isn't one, or
it would be impossible to get desynchronized) is what is lost.

The characters are characters, not *events*.  The WinMain is
not sent "events", it is sent *events*.


> Then, you transmit another command, and you receive the trailing bit
> that got left off, and most of your next command:

Yes.  There are "events" pending, but the notification of their arrival
(the *events*) has been lost.  Therefore when you get a new notification,
you get lost at some point back in time.

The point is that every time you get an *event*, you have to check for
more than one "event"; you can't assume, in Windows programming, that
there is a 1:1 correspondance (since, in this case, there obviously
isn't).

The easiest way to fix this is to "peek" the eventstack before exiting
the WinMain (similar to the XPending fix for the XEvent/select problem
in X when you don't implicit use XtMainLoop [or whatever it's called
today]).

This problem occurs because they are using the "async winsock", which
actually operates by way of a hidden window that does a select under
the covers, then calls Dispatch to send WinSock "events".

The better way to do this is to implement an async notification mechanism,
ala Windows NT, using a second thread that blocks in select and sends
notifications.

The Notification mechanism *does* work on Windows 95; you just have
to make an anonymous port using an fd of -1 to get an unbound-to-an-fd
notification point.  This is because in Windows 95, sockets are not
fd's; in Windows NT, they are.

A carefully architected interface can be transparently portable between
95 and NT (the one Microsoft gives you was not carefully architected).



> Not familiar with VNC.  Pointers?

Julian points out that there is a port.  8-).

But: http://www.orl.co.uk/vnc/


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806242019.NAA12612>