nanogui: Thread: multi-thread or multi-process?

Excuse my foolish question:
Is microwin multi-thread or multi-process?

On Tuesday, November 02, 1999 11:41 PM, ShenChong ####@####.#### wrote:
: 
: Excuse my foolish question:
: Is microwin multi-thread or multi-process?

Neither of Microwin's API's are multi-threaded currently.  The Nano-X api
is currently multi-process.

Greg

In /nano-X-0.4/examples/demo.c

main() call GrNewWindow() to create 5 window,

But GrNewWindow() doesn't fork.

It seems that window isn't a standalone process.

Am I right?

Is there any plan to change it?

On Thursday, November 04, 1999 6:54 PM, ShenChong ####@####.#### wrote:
: In /nano-X-0.4/examples/demo.c
: 
First, you should update and run the latest, approximately six months newer:
	http://microwindows.censoft.com/pub/microwindows

Get the microwindows-0.86.tar.gz



: main() call GrNewWindow() to create 5 window,
: 
: But GrNewWindow() doesn't fork.
: 
: It seems that window isn't a standalone process.
: 
: Am I right?
: 
No

: Is there any plan to change it?

The way Nano-X works, the _entire_ demo.c program is run as
a separate process.  All the windows that it creates, of course
using GrNewWindow, will be owned by that process.

If you want multiple applications, you create another demo1.c,
and run that program.  When it connects to the server via the GrOpen()
call, it can create windows also.  Thus Linux provides the multi-processing
if required, Microwindows doesn't really deal with this at all yet.

If people want it, I could add a threads API to Microwindows, but
I've been currently more worried about getting the graphics API
up, and not introducing dependencies on particular platform implementations.

Greg

> -----Original Message-----
> If people want it, I could add a threads API to Microwindows,

At this stage, when you think of the type of devices that Microwin is
aiming for (mainly linux based) Threads *MAY* be a good idea but....

> but
> I've been currently more worried about getting the graphics API
> up, and not introducing dependencies on particular platform
> implementations.

....but I have to say, I prefer this option -- perhaps we can have the
facility to have threads, later, not compiled in by default, the
developer has to "turn it on" (a la ./configure option?) as they
require. This way we have atleast one OS where threads works (Linux,
LinuxCE, whatever is easier) and then the developers for other OS' can
use that as a working example and template. Now I have to admit at this
stage I know very little about the deep inner workings of MicroWin but
can we have a /threads/ directory which if we
"./configure --with-threads" and the particular platform we are looking
for isn't in "/threads/arch/i386" (for example) then that particular
make can run minus threads support.  Being as most people won't be using
threads I don't think it'll matter too much :) Did any of that make
sence or is this still to early for me to be awake?

	-Darran (Friday Morning, officially the morning after my teams
	         meeting -- realistically the morning after we all got
	         hammered, wrecked and crashed in a field ;) )