Re: Suggested note to Checkpoint 5.5 on timeliness

Hans,

I cannot say much about this but you should not make assumptions on
Microsoft's position on this. There are ways to solve the security hole.

Other mechanisms to improve performance are bandaids compared with solving
this problem. They only provide marginal performance improvement.

>I may be wrong, but I do not think that the process-switches (even with
bursts of a hunderd per second) and data >copying (even several Kb per
second) account for most of the performance "losses" currently experienced
in >interprocess communication.

We have test results showing a 10X to 12X improvement in performance in our
labs.

Remember that Ian nicely changed the wording to remove "requires."

Rich

Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost


"Hans Riesebos" <HRiesebos@alva-bv.nl> on 03/08/2000 10:18:04 AM

To:   Richard Schwerdtfeger/Austin/IBM@IBMUS
cc:   "<" <w3c-wai-ua@w3.org>
Subject:  Re: Suggested note to Checkpoint 5.5 on timeliness




Rich,

our outSPOKEN makes happily use of in-process CPU-time and other priveleges
that come with it to build our OSM. We couldn't very well do it without.
The point is that going in-process in our case is a kind of security-hole
in the MS windows system (certainly for NT). Microsoft is discouraging this
way of working en looks for ways to solve this security-hole. The main
reason is that MS software (including the OS) crashes because of this kind
of practice. MS is left to proof that they did not crash but some other
program caused this and they are simply disbeliieved.

When MS software needed in process execution in MS software, that would be
entirely another case (as would Screen Reader software in OS/2).

I am totally aware that what we are asking from UA's is to voluntarily
execute (of course only bits of) AT-code in-process. If it is the consensus
of this working group that we mention this as a useful technique (in the
techniques document), than that is oke with me. For myself, I would like a
secure solution. If that means a bit less performance now, so be it. I
still think that there are more ways to improve performance.

I may be wrong, but I do not think that the process-switches (even with
bursts of a hunderd per second) and data copying (even several Kb per
second) account for most of the performance "losses" currently experienced
in interprocess communication.

Hans

>>> <schwer@us.ibm.com> 03/07/00 10:41PM >>>



Hans,

First, you don't architect your solution to have the entire AT software
package run in process with the application. You have only the portions
necessary to improve performance run in process with the application. We
did this very successfully in Screen Reader/2 when supporting Windows. If
you were to use the Java access bridge or the SVK to help support Java
appications you are successful also. Much of what you need can run in
process and if the Java app dies you only lose the part of the AT dealing
with that application which is dead anyway.

Also, if the main AT goes down the the part running in the UA should not go
down.

Given current technologies, in particular OSM it is extremely easy to not
only bring the application down but the entire system. Since ultimately the
OSM will run in process for all applications by virtue of the fact that it
is a DLL linked in the graphics call chain of the application. So, there is
nothing new that in-proces introduces that is not already an issue today
for other AT mechanisms for getting at information.

Your downside concerns are not warranted.

Rich

Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost


"Hans Riesebos" <HRiesebos@alva-bv.nl> on 03/07/2000 11:21:05 AM

To:   jongund@ux1.cso.uiuc.edu
cc:   "<" <w3c-wai-ua@w3.org>
Subject:  Re: Suggested note to Checkpoint 5.5 on timeliness




Rich wrote:

<PROPOSEDRICH>
>This checkpoint is designed to reduce delays that an assistive
>technology user might experience due to communication overhead when
>accessing
>parts of your application such as your DOM.
>Timely exchange is import for preventing loss of information,
>a risk when changes in content occur faster than the
>exchange with the assistive technology. One effective technique
>for providing timely access is to allow assistive technologies to run
>in the same process space as the user agent, thus eliminating
>inter-application communication delays.
></PROPOSEDRICH>
>

I'm really sorry that I only bring this "in process" argument to attention
now. I understood that the mention of "in process" would never make it to
the checkpoint-text (or notes with it).

Shouldn't we have techniques in the techniques document?

The argument:

"In process"  IS an effective technique. It has an important downside. If
the AT crashes "in process" it crashes the UA. The AT can also have the UA
crash by (inadvertently?) corrupt internal data of the UA. I am (almost)
sure this is not what a UA is willing to do.

A way to a solution?

The "in process" technique leads to three performance improvements:
1) No process switching needed
2) No waiting until the next process switch is needed
3) No copying of data needed (reaching other process's memory is not
possible on Win32 platforms. I am not sure but I believe it is possible on
the Macintosh)

Point 3 can be solved by using shared memory (is a technique). I am aware
that shared memory can be corrupted when it is writable.

Point 2 can be solved by giving higher (or equal?) priority to the
AT-process-threads or explicitly allowing a switch by the UA. I am aware
that the AT could starve the UA.

Point 1 can ONLY be solved by going "in process". It has the disadvantages
of data corruption AND the AT taking all the CPU time AND corruption of
internal UA-data.

Bottom-line.
In process is a technique that has great efficiency and a big downside. I
personally think the downside is too big to even recommend this technique.
It still is a technique and should (if mentioned) be mentioned in the
techniques document.

sincerely, Hans Riesebos
ALVA, The Netherlands
HRiesebos@alva-bv.nl

>>> Jon Gunderson <jongund@ux1.cso.uiuc.edu> 03/06/00 06:22PM >>>
Hans,

1. Would a clause that said:

"One effective technique in operating sytems that use separate process
spaces for providing timely access is to allow assistive technologies to
run in the same process space as the user agent, thus eliminating
inter-application communication delays"

2. Do you have any examples of what techniques would be useful on a
Macintosh operating system to support inter-process communication?

Thanks,
Jon


At 05:35 PM 3/6/00 +0100, Hans Riesebos wrote:
>I think that the "In process" must not be mentioned or at best be
mentioned
>in the techniques document (not in the guidelines).
>Letting an AT in process is a potential security hole! Also, for the
>Macintosh, there are no seperate process-spaces and therefore is in
process
>less meaningful.
>
>>>> Jon Gunderson <jongund@ux1.cso.uiuc.edu> 03/03/00 04:44PM >>>
>Note to checkpoint 5.5: This checkpoint is designed to promote the use of
>APIs which provide efficient exchange of information between user agents
>and assistive technologies.  Notably in multi-tasking operating systems
>this requires the ability to access the DOM and other Accessibility APIs
in
>process.  In process communication eliminates the time delays which occur
>with out-of-process communication between applications.  The time delays
>can result in slower response to user actions or potentially the user
>missing important information.
>
>Jon
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Chair, W3C WAI User Agent Working Group
>Division of Rehabilitation - Education Services
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: http://www.staff.uiuc.edu/~jongund
>WWW: http://www.w3.org/wai/ua
>
>

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Wednesday, 8 March 2000 11:29:03 UTC