NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/wizards/3805

Internet Message Format | 1992-09-07 | 4.5 KB

Xref: sparky comp.unix.wizards:3805 comp.unix.questions:10750 comp.windows.x:16202
Path: sparky!uunet!pmafire!news.dell.com!swrinde!zaphod.mps.ohio-state.edu!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!gateway.novell.com!thisbe!terry
From: [e-mail] (Terry Lambert)
Newsgroups: comp.unix.wizards,comp.unix.questions,comp.windows.x
Subject: Re: reliable signals under BSD / SVR4
Keywords: signals, reliable, software interrupts
Message-ID: <[e-mail]>
Date: 4 Sep 92 21:32:03 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: terry@thisbe (Terry Lambert)
Organization: Novell NPD -- Sandy, UT
Lines: 69
Nntp-Posting-Host: thisbe.eng.sandy.novell.com

In article <[e-mail]>, [e-mail] (Antony A. Courtney) writes:
|> In <[e-mail]> [e-mail] (Terry Lambert) writes:
|>
|> >In article <[e-mail]> [e-mail] (Antony A. Courtney) writes:
|> >>There are some "hacks" to get around this, if you're environment lets you
|> >>write the centralized control loop for the program.  But usually SIGIO is
|> >>useful in cases where that isn't possible, e.g. when using an X toolkit.
|> >
|> >    Wrong.  In XTMainAppLoop() in the X toolkit, there are hooks for
|> >adding input sources to be "select()"ed on.
|> > [...]
|>
|>     I didn't assert that it was totally impossible, just that it was a
|> "hack".  Adding extra input sources before passing control to XTMainAppLoop()
|> is a bit like saying "take over the control flow and tell me when something
|> happens that you understand (X events).  Oh, and also please tell me about
|> anything else that happens on these descriptors, even though you have no idea
|> what they are for and you don't know how to deal with them."  I humbly suggest
|> that this is hardly what one would call "elegant".

    Well, a hack's basically what you are doing.  The other method, which
*truly* is a hack, is to select on your descriptors AND the Xfd, and call an
unrolled XtMainAppLoop() for the processing of X events only.  Certainly the
registration of imput sources is more elegant than that.  And there's no
requirement that the input sources can not be registered as part of a callback
routine *after* entering XtMainAppLoop(), unless you are talking about command
line parameters on which the main thread of execution is supposed to act.

    The problem is that your application is using a toolkit at all, given the
non-event-driven nature of it, since a toolkit assumes that you will be doing
event callback processing.  This is fine for word processors and calculators
and such, but sucks out for anything with multiple input sources (like telnet or
xterm or talk).  There is a problem when you try to mix thread of execution
paradigms, like clasical procedural and event based programming styles.

    Perhaps what you really need is to start with XtMainAppLoop() as your
main procedural function, or simply use the object drawing code directly, if
what you are doing is antithetical to "toolkit" programming.

|> >    Read the fine manual.
|>
|>     I have read the fine manual on select() for my Unix system.  Too bad X
|> toolkits hide "all that underlying system control flow stuff" from me...

    Perhaps I was to flip here, in not siting the O'Reilly X Toolkit
programmer's guide (Hi Tim!  I want a commision!), seeing as you appear to
have gotten the impression I was referring to the UNIX manual page on select().
I was referring to where you would find documentation on the input registration
mechanisms I cited, not denigrating your desire to use select().

    Another alternative would be to download the X Toolkit from one of the
many ftp sites (export.lcs.mit.edu, gatekeeper.dec.com, wuarchive.wustl.edu,
etc.) and reimplement the main loop callback mechanism procedurally.  I did
this for "TERM for X Windows" with only a little difficulty about 2 or 2 1/2
years ago.

    I don't think anyone who has tried to do a complex job using an X
interface toolkit would argue that they are suitable for complex jobs; however,
I normally look at problems in light of "how can I *make* this work".  This is
pretty much how you can *make* it work.  Good luck on your problem.


                    Terry Lambert
                    [e-mail]
                    [e-mail]

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.