Re: XForms: Problems with synchronos processing

Marisa Giancarla (marisa@andromedia.com)
Fri, 12 Sep 1997 11:19:51 -0700 (PDT)

To subscribers of the xforms list from Marisa Giancarla <marisa@andromedia.com> :

>>>>> "SL" == Steve Lamont <spl@szechuan.ucsd.edu> writes:

SL> There's no need to use multiple threads when using I/O
SL> callbacks. You just add a handler to service the descriptor.
SL> It may require some small amount of state but if all you're
SL> doing is shoveling bits from one descriptor to another, I'm
SL> not sure you'd even need to do that. I see no need for
SL> special parsing.

If state is added via some global, and I set up a bunch of
flags to indicate what state it is in, it would be doable. However the
code would go from logical and simple to obscure and complex. There is
as I said bidirectional data transfer going on, and a single function
may be doing more than one interaction session. So for each of these
sessions I would need to create a totally new function to handle just
that small interaction slice, add yet more stack overhead to the
process, completely rewrite the low-level objects which expect to be
able to do their own bidirection interaction with the port before
handling the data they were requested to handle, etc. etc.

Having everything run out of the XForms loop is great for
programs that are primarily user interaction oriented, but when the
only user interaction is "click here to start process" and they
shouldn't be able to do anything with the app while that process is
running, it doesn't seem like a perfect match. The m,ajority of the
time things would be happening based on the normal xforms event
handling anyway, such as using the help functions, pull-down menus, or
the configuration panel.

The idea of breaking up a simple, non-user-interactive block
of code just to please the UI library and adding a lot of stack and
pointer setup overhead in timing critical loops where currently there
is none makes me queasy...

SL> I only suggest using I/O callbacks because it eventually is
SL> more general and flexible if the application needs to do other
SL> things while buffers are being shuffled by the O/S.

No, the app does not need to do anything else, and in fact
specifically should not be doing anything else. If I was to rewrite it
to use add_io_callback() the very first thing the callbacks from the
user interface buttons would do is totally disable all input and
response to user interaction until the low-level interaction was complete.

SL> However, it's your application and you know best what's
SL> needed.

I tried looking up using XFlush(), but that wants a display
arg passed. Does the xforms library provide an instance or a pointer
to a display struct already filled in with the current display? And is
the fact the changes I am making via the fl_set_object_label() calls
aren't shopwing up definately due to the lower-level Xlib layer and
not something in the Xforms layer?

Marisa

_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/