f



WinStartApp woes

Hi,

Im having the following problems with WinStartApp.
I have a DLL from where in I need to start a process Netscape and try
to grab the window handle to the window launched by using
WinQueryActiveWindow... API. Now the function call returns much before
the Netscape window gets active, so i need to keep polling after
sleeping some time. So we tried using a DosSleep to introduce some
delay, but it seems the netscape launch also blocks when i do a
DosSleep after a WinStartApp in my code. We tried having a separate
thread for the WinStartApp and sleeping in this thread. However it
seems the main thread keeps regaining control irrespective of the time
we sleep. We do not want to put a very large delay ( i suspect a very
large delay would yield the thread) since we need to report to the
front end ASAP.


I am not able to use DDE to communicate with Netscape since the process
that invokes my DLL does so using dynamic loading. It creates a new
thread every time it loads the DLL and when we use the WinCreateWindow,
it fails with an error 1036 meaning "no message queue".

Can anyone help me out, we are in a real tight spot.

Thanks in advance,
Chandan

0
maverick909
2/25/2005 9:16:00 PM
comp.os.os2.programmer.misc 1326 articles. 0 followers. Post Follow

84 Replies
630 Views

Similar Articles

[PageSpeed] 53

Hi,

1.) happ = WinStartApp(...)
2.) hswitch = WinHSWITCHfromHAPP(happ) /* undocumented, see Programming 
Guide and Addendum */
3.) WinQuerySwitchEntry(hswitch,&ctrl);

ctrl.hwnd should be the frame window handle.

Lars

maverick909 wrote:
> Hi,
> 
> Im having the following problems with WinStartApp.
> I have a DLL from where in I need to start a process Netscape and try
> to grab the window handle to the window launched by using
> WinQueryActiveWindow... API. Now the function call returns much before
> the Netscape window gets active, so i need to keep polling after
> sleeping some time. So we tried using a DosSleep to introduce some
> delay, but it seems the netscape launch also blocks when i do a
> DosSleep after a WinStartApp in my code. We tried having a separate
> thread for the WinStartApp and sleeping in this thread. However it
> seems the main thread keeps regaining control irrespective of the time
> we sleep. We do not want to put a very large delay ( i suspect a very
> large delay would yield the thread) since we need to report to the
> front end ASAP.
> 
> 
> I am not able to use DDE to communicate with Netscape since the process
> that invokes my DLL does so using dynamic loading. It creates a new
> thread every time it loads the DLL and when we use the WinCreateWindow,
> it fails with an error 1036 meaning "no message queue".
> 
> Can anyone help me out, we are in a real tight spot.
> 
> Thanks in advance,
> Chandan
> 
0
Lars
2/25/2005 10:20:19 PM
Thanks Lars,

Should try that out and get back for further problems. Im glad there is
always someone to answer here.

Regards,
Chandan

Lars Erdmann wrote:
> Hi,
>
> 1.) happ = WinStartApp(...)
> 2.) hswitch = WinHSWITCHfromHAPP(happ) /* undocumented, see
Programming
> Guide and Addendum */
> 3.) WinQuerySwitchEntry(hswitch,&ctrl);
>
> ctrl.hwnd should be the frame window handle.
>
> Lars
>
> maverick909 wrote:
> > Hi,
> >
> > Im having the following problems with WinStartApp.
> > I have a DLL from where in I need to start a process Netscape and
try
> > to grab the window handle to the window launched by using
> > WinQueryActiveWindow... API. Now the function call returns much
before
> > the Netscape window gets active, so i need to keep polling after
> > sleeping some time. So we tried using a DosSleep to introduce some
> > delay, but it seems the netscape launch also blocks when i do a
> > DosSleep after a WinStartApp in my code. We tried having a separate
> > thread for the WinStartApp and sleeping in this thread. However it
> > seems the main thread keeps regaining control irrespective of the
time
> > we sleep. We do not want to put a very large delay ( i suspect a
very
> > large delay would yield the thread) since we need to report to the
> > front end ASAP.
> >
> >
> > I am not able to use DDE to communicate with Netscape since the
process
> > that invokes my DLL does so using dynamic loading. It creates a new
> > thread every time it loads the DLL and when we use the
WinCreateWindow,
> > it fails with an error 1036 meaning "no message queue".
> >
> > Can anyone help me out, we are in a real tight spot.
> > 
> > Thanks in advance,
> > Chandan
> >

0
maverick909
2/26/2005 4:30:10 PM
Hi Lars,

Tried out this stuff. But it crashed my whole application although it
sis launch the browser. This is what Im trying to do -

I have a front end app that creates a thread and loads the DLL. I
launch Netscape using WinStartApp, after doing the PM
initialization(although im not sure if i need to initialize PM for
WinStartApp.) I do what you suggested
1.) happ = WinStartApp(...)
2.) hswitch = WinHSWITCHfromHAPP(happ) /* undocumented, see
3.) WinQuerySwitchEntry(hswitch,&ctrl);
On the 3rd line the application just quits. I guess it could be because
i dint get a valid handle from WinHSWitch(maybe the application hasnt
registered in the task list yet). Does this mean I will have to poll
for retrieving the handle. This would lead straight back to where I
started. Let me know what you think?


maverick909 wrote:
> Thanks Lars,
>
> Should try that out and get back for further problems. Im glad there
is
> always someone to answer here.
>
> Regards,
> Chandan
>
> Lars Erdmann wrote:
> > Hi,
> >
> > 1.) happ = WinStartApp(...)
> > 2.) hswitch = WinHSWITCHfromHAPP(happ) /* undocumented, see
> Programming
> > Guide and Addendum */
> > 3.) WinQuerySwitchEntry(hswitch,&ctrl);
> >
> > ctrl.hwnd should be the frame window handle.
> >
> > Lars
> >
> > maverick909 wrote:
> > > Hi,
> > >
> > > Im having the following problems with WinStartApp.
> > > I have a DLL from where in I need to start a process Netscape and
> try
> > > to grab the window handle to the window launched by using
> > > WinQueryActiveWindow... API. Now the function call returns much
> before
> > > the Netscape window gets active, so i need to keep polling after
> > > sleeping some time. So we tried using a DosSleep to introduce
some
> > > delay, but it seems the netscape launch also blocks when i do a
> > > DosSleep after a WinStartApp in my code. We tried having a
separate
> > > thread for the WinStartApp and sleeping in this thread. However
it
> > > seems the main thread keeps regaining control irrespective of the
> time
> > > we sleep. We do not want to put a very large delay ( i suspect a
> very
> > > large delay would yield the thread) since we need to report to
the
> > > front end ASAP.
> > >
> > >
> > > I am not able to use DDE to communicate with Netscape since the
> process
> > > that invokes my DLL does so using dynamic loading. It creates a
new
> > > thread every time it loads the DLL and when we use the
> WinCreateWindow,
> > > it fails with an error 1036 meaning "no message queue".
> > >
> > > Can anyone help me out, we are in a real tight spot.
> > > 
> > > Thanks in advance,
> > > Chandan
> > >

0
maverick909
3/4/2005 10:31:25 PM
On Fri, 4 Mar 2005 22:31:25 UTC, "maverick909" 
<gupta.chandan@gmail.com> wrote:

> Hi Lars,
> 
> Tried out this stuff. But it crashed my whole application although it
> sis launch the browser. This is what Im trying to do -
> 
> I have a front end app that creates a thread and loads the DLL. I
> launch Netscape using WinStartApp, after doing the PM
> initialization(although im not sure if i need to initialize PM for
> WinStartApp.) 

WinStartApp needs a message queue.
WinInitialise() 
WinCreateMsgQueue()

When the program specified by the application handle terminates, the 
window specified by the hwndNotify parameter (if the window still 
exists and is valid) has a WM_APPTERMINATENOTIFY message posted to it 
to notify it of the application termination. 

For more details and an example read the Presentation Manager Guide 
and Reference.

> I do what you suggested
> 1.) happ = WinStartApp(...)
> 2.) hswitch = WinHSWITCHfromHAPP(happ) /* undocumented, see
> 3.) WinQuerySwitchEntry(hswitch,&ctrl);
> On the 3rd line the application just quits. I guess it could be because
> i dint get a valid handle from WinHSWitch(maybe the application hasnt
> registered in the task list yet). Does this mean I will have to poll
> for retrieving the handle. This would lead straight back to where I
> started. Let me know what you think?

You have not created a message queue. WinStartApp() returns when the 
app is created - but that does not mean that it had get enough CPU to 
create its window(s)!

When WinStartApp() returns successfully you would POST yourself a 
WM_USER that checks for the applications window in the tasklist when 
you needs to communicate with that. Repeat until the window is there. 
You may sleep a little bit before you starts the check to give CPU 
away.

Hint: create an object window after you have created the messagequeue.
Use that objectwindow to handle the communication with the app you've 
started.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/5/2005 11:39:04 AM
Did you follow my suggestion on another group/thread? WM_TIMER etc

This is perfectly straightforward if you follow the advice I gave 
there..

Suddenly, maverick909 sprang forth and uttered these pithy words:
> Hi,
> 
> Im having the following problems with WinStartApp.
> I have a DLL from where in I need to start a process Netscape and try
> to grab the window handle to the window launched by using
> WinQueryActiveWindow... API. Now the function call returns much before
> the Netscape window gets active, so i need to keep polling after
> sleeping some time. So we tried using a DosSleep to introduce some
> delay, but it seems the netscape launch also blocks when i do a
> DosSleep after a WinStartApp in my code. We tried having a separate
> thread for the WinStartApp and sleeping in this thread. However it
> seems the main thread keeps regaining control irrespective of the time
> we sleep. We do not want to put a very large delay ( i suspect a very
> large delay would yield the thread) since we need to report to the
> front end ASAP.
> 
> 
> I am not able to use DDE to communicate with Netscape since the process
> that invokes my DLL does so using dynamic loading. It creates a new
> thread every time it loads the DLL and when we use the WinCreateWindow,
> it fails with an error 1036 meaning "no message queue".
> 
> Can anyone help me out, we are in a real tight spot.
> 
> Thanks in advance,
> Chandan
> 
> 

-- 
aaronl at consultant dot com 
For every expert, there is an equal and 
opposite expert. - Arthur C. Clarke
0
Aaron
3/5/2005 1:57:29 PM
Hi Aaaron/Herbert,

Thanks for the help.

I did follow your suggestion to use WM_TIMER to induce the delay. But I
had the same results. I guess what I was doing wrong was to do a
WinstartApp before creating a message queue and starting up my polling
/ control window. Maybe if I startup the application in WM_CREATE of my
polling window then things might work.

I have one more doubt, the thread in which im creating the window is a
secondary thread and is it ok to post a WM_QUIT to the polling window
and handle the message destroying the message queue. I have to
basically give an API call to the front end to start netscape and grab
the handle for the netscape window.
What say you?

Regards,
Chandan

0
maverick909
3/5/2005 2:51:59 PM
Hmmm,

Looks like im doing something really stupid. Nothing seems to work out.
Im using IBM C/C++ compilers 3.6

A very detailed description of my problem.
1. There is a front end PM application window which makes some API
calls into a DLL.
2. For each API call it spawns a new thread and waits till the thread
dies. (Im using DosCreateThread and DosWait).
3.Now the DLL called relays it to another DLL, which essentially calls
WinStartApp to launch netscape.
4. The function which calls WinStartApp does the following -
WinInitialize, WinCreateMsgQueue,WinCreateWindow, WinStartApp and then
starts up a messsage loop.
5. Now in the WM_CREATE of the window created it sets upa timer for 500
milliseconds and keeps polling the active desktop window.
6. Each time the timer goes off it does a WinQueryActiveDesktop window
and then WinQueryWindowText.

Strangely enough the app hangs and Netscape doesnt launch, logs show
that the app hung after querying the active desktop handle while trying
to get the window title. If i remove the winquerytext the app keeps
setting off the timer however netscape window is never launched. What
am I doing wrong here? Im in a really tight spot. I tried moving
WinStartApp to WM_CREATE handler of the window with identical results.

Should I try some other API? maybe DosExecPgm or DosStartSession I
would have better luck? Is this something peculiar to WinStartApp? Or
should I get a different process to start up netscape by posting it a
WM_USER message?

Regards,
Chandan

maverick909 wrote:
> Hi Aaaron/Herbert,
>
> Thanks for the help.
>
> I did follow your suggestion to use WM_TIMER to induce the delay. But
I
> had the same results. I guess what I was doing wrong was to do a
> WinstartApp before creating a message queue and starting up my
polling
> / control window. Maybe if I startup the application in WM_CREATE of
my
> polling window then things might work.
>
> I have one more doubt, the thread in which im creating the window is
a
> secondary thread and is it ok to post a WM_QUIT to the polling window
> and handle the message destroying the message queue. I have to
> basically give an API call to the front end to start netscape and
grab
> the handle for the netscape window.
> What say you?
> 
> Regards,
> Chandan

0
maverick909
3/5/2005 10:54:44 PM
On Sat, 5 Mar 2005 22:54:44 UTC, "maverick909" 
<gupta.chandan@gmail.com> wrote:

> Hmmm,
> 
> Looks like im doing something really stupid. Nothing seems to work out.
> Im using IBM C/C++ compilers 3.6
> 
> A very detailed description of my problem.
> 1. There is a front end PM application window which makes some API
> calls into a DLL.
> 2. For each API call it spawns a new thread and waits till the thread
> dies. (Im using DosCreateThread and DosWait).

This hungs PM because the main thread does not return from its 
message. DON'T wait for the tread actively. Create the thread and 
return from the message immediately! Let the thread that handles the 
app send a message that it is dying because it has done anything it 
should. For That WM_USER(+x) is there.

Why does you fire up threads when you blocks yourself until the thread
is finish. Makes absolutely no sense. 

> 3.Now the DLL called relays it to another DLL, which essentially calls
> WinStartApp to launch netscape.
> 4. The function which calls WinStartApp does the following -
> WinInitialize, WinCreateMsgQueue,WinCreateWindow, WinStartApp and then
> starts up a messsage loop.
> 5. Now in the WM_CREATE of the window created it sets upa timer for 500
> milliseconds and keeps polling the active desktop window.
> 6. Each time the timer goes off it does a WinQueryActiveDesktop window
> and then WinQueryWindowText.

The chance that the active window is NOT the one you looks for is 
higher than that it is. Seach the tasklist for the window of the app. 
When it is in the tasklist you knows that the app has finished its 
startup and you can start to communicate with the window.
 
> Strangely enough the app hangs and Netscape doesnt launch, logs show
> that the app hung after querying the active desktop handle while trying
> to get the window title. If i remove the winquerytext the app keeps
> setting off the timer however netscape window is never launched. What
> am I doing wrong here? Im in a really tight spot. I tried moving
> WinStartApp to WM_CREATE handler of the window with identical results.

You blocks the system message queue in you main thread.

When YOUR app is closing down it is the time you have to wait for all 
threads to be shutted down but not while you in active message 
processing.
 
> Should I try some other API? maybe DosExecPgm or DosStartSession I
> would have better luck? 

No. You have selected the best possible one for that.

Is this something peculiar to WinStartApp? Or
> should I get a different process to start up netscape by posting it a
> WM_USER message?

No. But you have to do your message handling right.

When you have to start multiple apps I would fire up a thread that 
does this kind of work and would never shutdown it.

The only change were:
After creating the message queue and creating your (object)window and 
any other initialisation of that thread enter your message queue.

Whenever the (object)window receives the WM_USER requirering the start
of another app - do it. Then setup the timer.

When the timer goes off check the tasklist for the window you awaits. 
When the window is there stop the timer and do what ever you would 
with the window.
WinStartApp will sends you a message when the app you've fired up is 
finished. So you can do whatever you likes to do on that event, e.g. 
inform the main thread about it too (WM_USER).

You gets the same done without timer:
When WinStartApp returns successfully DosSleep(64L) (that is 2 CPU 
timeslices) to give the app time to run, then POST a WM_USER to 
yourself.
When you receives it check the tasklist and when the window is NOT 
there DosSleep(32L) and post the same WM_USER again. DosSleep(0) is 
useless, DosSleep(1) will only give up the current timeslice so the 
64/32 saves some useless message handling even as there can be some 
but saves you the concentration for the timer handling. 

In you main thread whenever you have to fire up another app you would 
simply _post_ a WM_USER(+x) to the thread window requirering the start
of the app.
You have 2 message parameters to send some data with! When 

Hint: when the thread has no interaction with the user (except one or 
more messageboxes) create an object window instead of a regular one. 
An object windoe receives no messages from PM - but will handle all 
messages you sends/posts it. Handle the WM_CLOSE (sended from main 
thread) and any other you likes.

In short:
startup app:
- data initialision
- PM initialision
- HELP initialision
- create main window
- create threads you use
- message loop
- cleanup data as needed
- shutdown other threads and wait for shutted down
  You MUST wait for all threads shutted down here because
  the main will crash sometimes in shudown itself when a
  thread is not removed from the list of active threads.
- destroy helpmanager
- destroy window(s)
- return

PM-Thread:
- data initialision
- PM initialision
- HELP initialision
- create main window
- create threads you use
- message loop
- cleanup data as needed
- destroy helpmanager
- destroy window(s)
- return

There are important rules in programming PM:
- No message should run longer than 1/10s until it returns to PM.
  Whenever an action can use more time create a thread (or use an
  already created) and let do it what is needed
- you will SEND a message whenever you needs its result
  that is working on the message syncronous. The 1/10s rule
  includes the time of any message you send and gets sended
  from the destination!
  WinSendMsg returns the result of the message itself
- you will POST a message when you needs an action done but
  has no need to wait for the result.
  This starts another 1/10s period on its own
  This is working asyncronous.
  WinPostMsg returns only a flag: post was (un)successfull
  When the result of the action is needed the receiver
  should send/post it in another message.
- use DosSleep() only for very short wait time because rule 1 counts.
  Avoid it whenever possible. For that the timers are there.
  DosSleep() is good for giving up the current timeslice
- You would use DosEnterCritSec() to get the CPU exclusive for
  the thread in the application it is running in. It does not
  block other threads in other applications from CPU.
  DosEnterCritSec() gets removed implicity by most APIs and
  after a short time periode. But is elegant to manipulate
  a handful application wide shared variables quickly.
  The critical section endeds implicity when the thread
  called it is removed from the list of active threads. But
  is ideal to do some handling between sending a message that
  the thread IS die and the real die as the receiving thread in
  the same process will only get CPU when the dying thread IS die.
- DosExitCritSec() should be called so quick as possible after
  DosEnterCritSec(). It gets called implicity in _endthread() and
  return in a thread.
- DosWaitThread
  blocks the PM message queue until the thread waiting for is dead!
  Avoid that API until you have leaved the message loop

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/6/2005 10:40:09 AM
Thanks Herbert,

for such a detailed reply. However  I want to make sure that i
understood somethings correctly.

1. > This hungs PM because the main thread does not return from its
> message. DON'T wait for the tread actively. Create the thread and
> return from the message immediately! Let the thread that handles the
> app send a message that it is dying because it has done anything it
> should. For That WM_USER(+x) is there.
I can not help this, this is existing front end behaviour. It will call
all APIs in another thread and wait for it to stop. However its UI
remains active. I think you are suggestingto have a separate thread to
start up multiple applications. Im not sure about this. Should I create
a different process just to start up the applications, which has a main
thread that does that?
Can I use a DLL to share the data between this process and the other
process which will actually do the polling.

Herbert Rosenau wrote:
> On Sat, 5 Mar 2005 22:54:44 UTC, "maverick909"
> <gupta.chandan@gmail.com> wrote:
>
> > Hmmm,
> >
> > Looks like im doing something really stupid. Nothing seems to work
out.
> > Im using IBM C/C++ compilers 3.6
> >
> > A very detailed description of my problem.
> > 1. There is a front end PM application window which makes some API
> > calls into a DLL.
> > 2. For each API call it spawns a new thread and waits till the
thread
> > dies. (Im using DosCreateThread and DosWait).
>
> This hungs PM because the main thread does not return from its
> message. DON'T wait for the tread actively. Create the thread and
> return from the message immediately! Let the thread that handles the
> app send a message that it is dying because it has done anything it
> should. For That WM_USER(+x) is there.
>
> Why does you fire up threads when you blocks yourself until the
thread
> is finish. Makes absolutely no sense.
>
> > 3.Now the DLL called relays it to another DLL, which essentially
calls
> > WinStartApp to launch netscape.
> > 4. The function which calls WinStartApp does the following -
> > WinInitialize, WinCreateMsgQueue,WinCreateWindow, WinStartApp and
then
> > starts up a messsage loop.
> > 5. Now in the WM_CREATE of the window created it sets upa timer for
500
> > milliseconds and keeps polling the active desktop window.
> > 6. Each time the timer goes off it does a WinQueryActiveDesktop
window
> > and then WinQueryWindowText.
>
> The chance that the active window is NOT the one you looks for is
> higher than that it is. Seach the tasklist for the window of the app.

> When it is in the tasklist you knows that the app has finished its
> startup and you can start to communicate with the window.
>
> > Strangely enough the app hangs and Netscape doesnt launch, logs
show
> > that the app hung after querying the active desktop handle while
trying
> > to get the window title. If i remove the winquerytext the app keeps
> > setting off the timer however netscape window is never launched.
What
> > am I doing wrong here? Im in a really tight spot. I tried moving
> > WinStartApp to WM_CREATE handler of the window with identical
results.
>
> You blocks the system message queue in you main thread.
>
> When YOUR app is closing down it is the time you have to wait for all

> threads to be shutted down but not while you in active message
> processing.
>
> > Should I try some other API? maybe DosExecPgm or DosStartSession I
> > would have better luck?
>
> No. You have selected the best possible one for that.
>
> Is this something peculiar to WinStartApp? Or
> > should I get a different process to start up netscape by posting it
a
> > WM_USER message?
>
> No. But you have to do your message handling right.
>
> When you have to start multiple apps I would fire up a thread that
> does this kind of work and would never shutdown it.
>
> The only change were:
> After creating the message queue and creating your (object)window and

> any other initialisation of that thread enter your message queue.
>
> Whenever the (object)window receives the WM_USER requirering the
start
> of another app - do it. Then setup the timer.
>
> When the timer goes off check the tasklist for the window you awaits.

> When the window is there stop the timer and do what ever you would
> with the window.
> WinStartApp will sends you a message when the app you've fired up is
> finished. So you can do whatever you likes to do on that event, e.g.
> inform the main thread about it too (WM_USER).
>
> You gets the same done without timer:
> When WinStartApp returns successfully DosSleep(64L) (that is 2 CPU
> timeslices) to give the app time to run, then POST a WM_USER to
> yourself.
> When you receives it check the tasklist and when the window is NOT
> there DosSleep(32L) and post the same WM_USER again. DosSleep(0) is
> useless, DosSleep(1) will only give up the current timeslice so the
> 64/32 saves some useless message handling even as there can be some
> but saves you the concentration for the timer handling.
>
> In you main thread whenever you have to fire up another app you would

> simply _post_ a WM_USER(+x) to the thread window requirering the
start
> of the app.
> You have 2 message parameters to send some data with! When
>
> Hint: when the thread has no interaction with the user (except one or

> more messageboxes) create an object window instead of a regular one.
> An object windoe receives no messages from PM - but will handle all
> messages you sends/posts it. Handle the WM_CLOSE (sended from main
> thread) and any other you likes.
>
> In short:
> startup app:
> - data initialision
> - PM initialision
> - HELP initialision
> - create main window
> - create threads you use
> - message loop
> - cleanup data as needed
> - shutdown other threads and wait for shutted down
>   You MUST wait for all threads shutted down here because
>   the main will crash sometimes in shudown itself when a
>   thread is not removed from the list of active threads.
> - destroy helpmanager
> - destroy window(s)
> - return
>
> PM-Thread:
> - data initialision
> - PM initialision
> - HELP initialision
> - create main window
> - create threads you use
> - message loop
> - cleanup data as needed
> - destroy helpmanager
> - destroy window(s)
> - return
>
> There are important rules in programming PM:
> - No message should run longer than 1/10s until it returns to PM.
>   Whenever an action can use more time create a thread (or use an
>   already created) and let do it what is needed
> - you will SEND a message whenever you needs its result
>   that is working on the message syncronous. The 1/10s rule
>   includes the time of any message you send and gets sended
>   from the destination!
>   WinSendMsg returns the result of the message itself
> - you will POST a message when you needs an action done but
>   has no need to wait for the result.
>   This starts another 1/10s period on its own
>   This is working asyncronous.
>   WinPostMsg returns only a flag: post was (un)successfull
>   When the result of the action is needed the receiver
>   should send/post it in another message.
> - use DosSleep() only for very short wait time because rule 1 counts.
>   Avoid it whenever possible. For that the timers are there.
>   DosSleep() is good for giving up the current timeslice
> - You would use DosEnterCritSec() to get the CPU exclusive for
>   the thread in the application it is running in. It does not
>   block other threads in other applications from CPU.
>   DosEnterCritSec() gets removed implicity by most APIs and
>   after a short time periode. But is elegant to manipulate
>   a handful application wide shared variables quickly.
>   The critical section endeds implicity when the thread
>   called it is removed from the list of active threads. But
>   is ideal to do some handling between sending a message that
>   the thread IS die and the real die as the receiving thread in
>   the same process will only get CPU when the dying thread IS die.
> - DosExitCritSec() should be called so quick as possible after
>   DosEnterCritSec(). It gets called implicity in _endthread() and
>   return in a thread.
> - DosWaitThread
>   blocks the PM message queue until the thread waiting for is dead!
>   Avoid that API until you have leaved the message loop
>
> --
> Tschau/Bye
> Herbert
>
> Visit http://www.ecomstation.de the home of german eComStation
> eComStation 1.2 Deutsch ist da!

0
maverick909
3/6/2005 1:32:00 PM
On Sun, 6 Mar 2005 13:32:00 UTC, "maverick909" 
<gupta.chandan@gmail.com> wrote:

> Thanks Herbert,
> 
> for such a detailed reply. However  I want to make sure that i
> understood somethings correctly.
> 
> 1. > This hungs PM because the main thread does not return from its
> > message. DON'T wait for the tread actively. Create the thread and
> > return from the message immediately! Let the thread that handles the
> > app send a message that it is dying because it has done anything it
> > should. For That WM_USER(+x) is there.
> I can not help this, this is existing front end behaviour. It will call
> all APIs in another thread and wait for it to stop.

Solong you can't change the behavior of the caller of the thread to 
NOT waiting for ehe end of the thread you would not be able to get 
anything working right when the program doing so is related to 
handling PM messages.

But as you have to write a new thread you would be able to change the 
program.
Oh stop, when the program gives you only an interface to a DLL then 
you're right. But with that you would fire up another thread to do the
real work and end the initial thread immediately.

 However its UI
> remains active. I think you are suggestingto have a separate thread to
> start up multiple applications.

Yes - but at least you can use the same technique for firing up one 
single app. When that is the job of the thread you can give anything 
you needs as parameter (commonly a self defined structure) to the 
thread or use something else. 

 Im not sure about this. Should I create
> a different process just to start up the applications, which has a main
> thread that does that?

You should fire up another thread to do the real work and close the 
thread that is initiated from the main so quickly as possible to let 
the main go further. But then you would have no chance to inform the 
ill behaved main about failed startup of the app.

> Can I use a DLL to share the data between this process and the other
> process which will actually do the polling.

It doesn't matter if code is in a DLL or in a program. With any type 
of program you can share data between programs by
- using a pipe
- using a queue
- using shared memory with and without a pipe/queue
You would use semaphores to coordinate the access to the data anyway.

With PM programs you can use shared memory between programs in 
conjunction with PM messages and only PM messages when any data to 
share fits in 2 32bit variables (the message parameters). 

You can share data between a program and a DLL like you shares code or
between different translation modules.

You can share data by using shared data segments - it is the job of 
the linker to bind them to the program/different DLLs. Read the 
documentation about .DEF files carefully. The .DEF is the key for 
binding a program and a DLL and/or DLLs together.

Yea, the .DEF speaks about segments as if it were 16 bit code - but 
that is only reuse of the name "segment" as a groups of 32 bit pages 
with different access rights. You would use your own "segment(s)" to 
give  grous of pages different access rights as the standard 
"segments" offers.

You can simply dynamically memory using DosAllocSharedMem() ang give 
that memory to the app needing it.

You would read the ControlProgram Programming Guide and Reference for 
that,
Presentation Manager Programming Guide and Reference for PM 
programming, Programming Guide and Reference Addendum for APIs 
released with WARP4 FP13 and later, Tools Reference for e.g Module 
Definition Files (.DEF) and linking.

The books gets installed with the toolkit.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/6/2005 6:55:12 PM
Thanks so much herbert,

Your reply gave me another idea. What if I were to create a PM thread
when the DLL was first loaded in the memory and have it destroyed once
the DLL gets unloaded? Maybe I can load the DLL once myself when the
DLL gets loaded. This is because that stupid front end also unloads the
DLL when it is done with an API call. This thread can have a WM_USER
message for polling. while I can use WinStartApp in my main thread.
Does that sound ok to you. I dont have much time to play around with
shared memory and other stuff for Inter Process communication.
Herbert Rosenau wrote:
> On Sun, 6 Mar 2005 13:32:00 UTC, "maverick909"
> <gupta.chandan@gmail.com> wrote:
>
> > Thanks Herbert,
> >
> > for such a detailed reply. However  I want to make sure that i
> > understood somethings correctly.
> >
> > 1. > This hungs PM because the main thread does not return from its
> > > message. DON'T wait for the tread actively. Create the thread and
> > > return from the message immediately! Let the thread that handles
the
> > > app send a message that it is dying because it has done anything
it
> > > should. For That WM_USER(+x) is there.
> > I can not help this, this is existing front end behaviour. It will
call
> > all APIs in another thread and wait for it to stop.
>
> Solong you can't change the behavior of the caller of the thread to
> NOT waiting for ehe end of the thread you would not be able to get
> anything working right when the program doing so is related to
> handling PM messages.
>
> But as you have to write a new thread you would be able to change the

> program.
> Oh stop, when the program gives you only an interface to a DLL then
> you're right. But with that you would fire up another thread to do
the
> real work and end the initial thread immediately.
>
>  However its UI
> > remains active. I think you are suggestingto have a separate thread
to
> > start up multiple applications.
>
> Yes - but at least you can use the same technique for firing up one
> single app. When that is the job of the thread you can give anything
> you needs as parameter (commonly a self defined structure) to the
> thread or use something else.
>
>  Im not sure about this. Should I create
> > a different process just to start up the applications, which has a
main
> > thread that does that?
>
> You should fire up another thread to do the real work and close the
> thread that is initiated from the main so quickly as possible to let
> the main go further. But then you would have no chance to inform the
> ill behaved main about failed startup of the app.
>
> > Can I use a DLL to share the data between this process and the
other
> > process which will actually do the polling.
>
> It doesn't matter if code is in a DLL or in a program. With any type
> of program you can share data between programs by
> - using a pipe
> - using a queue
> - using shared memory with and without a pipe/queue
> You would use semaphores to coordinate the access to the data anyway.
>
> With PM programs you can use shared memory between programs in
> conjunction with PM messages and only PM messages when any data to
> share fits in 2 32bit variables (the message parameters).
>
> You can share data between a program and a DLL like you shares code
or
> between different translation modules.
>
> You can share data by using shared data segments - it is the job of
> the linker to bind them to the program/different DLLs. Read the
> documentation about .DEF files carefully. The .DEF is the key for
> binding a program and a DLL and/or DLLs together.
>
> Yea, the .DEF speaks about segments as if it were 16 bit code - but
> that is only reuse of the name "segment" as a groups of 32 bit pages
> with different access rights. You would use your own "segment(s)" to
> give  grous of pages different access rights as the standard
> "segments" offers.
>
> You can simply dynamically memory using DosAllocSharedMem() ang give
> that memory to the app needing it.
>
> You would read the ControlProgram Programming Guide and Reference for

> that,
> Presentation Manager Programming Guide and Reference for PM
> programming, Programming Guide and Reference Addendum for APIs
> released with WARP4 FP13 and later, Tools Reference for e.g Module
> Definition Files (.DEF) and linking.
>
> The books gets installed with the toolkit.
>
> --
> Tschau/Bye
> Herbert
>
> Visit http://www.ecomstation.de the home of german eComStation
> eComStation 1.2 Deutsch ist da!

0
maverick909
3/6/2005 9:30:12 PM
On Sun, 6 Mar 2005 21:30:12 UTC, "maverick909" 
<gupta.chandan@gmail.com> wrote:

> Thanks so much herbert,
> 
> Your reply gave me another idea. What if I were to create a PM thread
> when the DLL was first loaded in the memory and have it destroyed once
> the DLL gets unloaded? Maybe I can load the DLL once myself when the
> DLL gets loaded. This is because that stupid front end also unloads the
> DLL when it is done with an API call. This thread can have a WM_USER
> message for polling. while I can use WinStartApp in my main thread.
> Does that sound ok to you. I dont have much time to play around with
> shared memory and other stuff for Inter Process communication.
> Herbert Rosenau wrote:

That it's. There a 2 methods to get a DLL loaded_

1. static
   That is let the program loader do the work while the program
   gets up running.

   Adventage: The loader does it implicity
   Adventage: no code for DLL loading needed

   Disadventage: DLL eats memory even when it is not used
   Disadventage: loadtime of the program increases
   Disadventage: the whole program must stopped and
                 restarted when the DLL must be replaced

2. dynamically
   Adventage: program gets loaded quicker
   Adventage: saves memory until DLL is needed
   Adventage: DLL can be unloaded when not needed
   Adventage: exchange of a DLL is easier

   Disadventage: loading DLL costs time
   Disadventage: load can fail

When a DLL is needed seldom it makes sense to load it only when it is 
needed and unload it thereafter. It can make sense to never unload a 
dynamically loaded DLL. This is e.g. when the chance that it gets 
reused shortenly after it gets unused is high.

As you have to work against flaws of the whole app without a chance to
correct the source of the app I would trash the whole app and rewrite 
it from crash.
It make no sense to load/unload/load.... a DLL for each single API. It
makes no sense to block the mainthread until a little pice of work is 
done. The current app is pure crap.

You have NO chance to stink against the bugs in the main except that 
runs until the computer gets switched off (system shutdown 
impossible). That means
- you can't unload a DLL that is active (a thread in it is not closed)
- you can't exit an application that has an active thread
  in best you gets the app crashed in its exit,
  else you gets a zombie eating your RAM     

Unpleasant solution:
1. when the DLL gets loaded the first time: fire up another app
   to do YOUR work
   problem: there is nothing that will be able to shutdown it.
            gives you the same problem as with separately loaded DLL
   problem: firing up an application costs 100 times the time to 
            fire up a thread
   problem: on a reload of the DLL that starts your action you must
            - find out that the app is already active
            - find out its HWND
            until you can interact with it
2. you must again and again... determine the HWND in that app
   this is a relative complex action.
   
optimal solution:
find the developer of the program and let him fix the problems
OR find the source and fix it yourself
- wait for the thread in a message loop
  He waits for success of the API in the DLL
  PM way is: receiving a WM_USER that tells about fail/success
             and do the approviate action(s) then
- NOT load/unload the DLL constantly, but one time
  that can include dynamic thread starts OR
   onetime thread that looks for WM_USER to start an action
Here you have a chance to debug YOUR work while the developer is 
fixing his problems:
Write a little PM app that does the minimum actions to load the DLL 
your startpoint is and test and debug your code. When the developer 
comes with his fix you're ready.

Compromise:
can give you the same problems as with the unplesant solution!
Like the unplesant solution but insteat firing up an app to do your 
work load another DLL.

As sayed before: WM_USER is the key to decouple actions with PM. 
As you can send/post any message to any window in the system it is 
only you who decides which message to send to which window. PM and 
OS/2 gives you anything to find out an HWND when you knows a bit about
the window to identify it. You can enumerate windows, you can query 
the task list, you can query the process list....

You would know that you loose any information about anything when the 
DLL you holds the data gets unloaded. So you have to search the system
again and again.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/7/2005 8:17:31 AM
Is it really necessary to have all these steps in place?

In cases like this I usually go back to the basics. In this case I would 
create a very small PM application that does this:

- initialises PM for itself
- creates its window/starts message loop
- in WM_CREATE set up a timer
now in message proc:
- on the first timer, launch Netscape with WinStartApp
- on subsequent timers, look in the tasklist/active window

NO [EXTRA] THREADS! 

Perhaps you have a deadlock between getting the window text and Netscape 
itself starting up....

Also another guy was posting on this group about using DDE to control 
Netscape and seemed to have most of it working...?

If you write a SMALL example code as above and still have problems, send 
it to me and I will try to help.


Suddenly, maverick909 sprang forth and uttered these pithy words:
> Hmmm,
> 
> Looks like im doing something really stupid. Nothing seems to work out.
> Im using IBM C/C++ compilers 3.6
> 
> A very detailed description of my problem.
> 1. There is a front end PM application window which makes some API
> calls into a DLL.
> 2. For each API call it spawns a new thread and waits till the thread
> dies. (Im using DosCreateThread and DosWait).
> 3.Now the DLL called relays it to another DLL, which essentially calls
> WinStartApp to launch netscape.
> 4. The function which calls WinStartApp does the following -
> WinInitialize, WinCreateMsgQueue,WinCreateWindow, WinStartApp and then
> starts up a messsage loop.
> 5. Now in the WM_CREATE of the window created it sets upa timer for 500
> milliseconds and keeps polling the active desktop window.
> 6. Each time the timer goes off it does a WinQueryActiveDesktop window
> and then WinQueryWindowText.
> 
> Strangely enough the app hangs and Netscape doesnt launch, logs show
> that the app hung after querying the active desktop handle while trying
> to get the window title. If i remove the winquerytext the app keeps
> setting off the timer however netscape window is never launched. What
> am I doing wrong here? Im in a really tight spot. I tried moving
> WinStartApp to WM_CREATE handler of the window with identical results.
> 
> Should I try some other API? maybe DosExecPgm or DosStartSession I
> would have better luck? Is this something peculiar to WinStartApp? Or
> should I get a different process to start up netscape by posting it a
> WM_USER message?
> 
> Regards,
> Chandan
> 
> maverick909 wrote:
> > Hi Aaaron/Herbert,
> >
> > Thanks for the help.
> >
> > I did follow your suggestion to use WM_TIMER to induce the delay. But
> I
> > had the same results. I guess what I was doing wrong was to do a
> > WinstartApp before creating a message queue and starting up my
> polling
> > / control window. Maybe if I startup the application in WM_CREATE of
> my
> > polling window then things might work.
> >
> > I have one more doubt, the thread in which im creating the window is
> a
> > secondary thread and is it ok to post a WM_QUIT to the polling window
> > and handle the message destroying the message queue. I have to
> > basically give an API call to the front end to start netscape and
> grab
> > the handle for the netscape window.
> > What say you?
> > 
> > Regards,
> > Chandan
> 
> 

-- 
aaronl at consultant dot com 
For every expert, there is an equal and 
opposite expert. - Arthur C. Clarke
0
Aaron
3/7/2005 2:58:34 PM
Well that guy was me. DDE had worked pretty well but it dint use to
give me the window state for netscape windows, for all other purposes
it was sufficient. Not to mention the Protocol handler is crap.Thanks
you guys for the help but luckily this project seems to have wound up.
For some reason even when front end unloads the DLL, the global data is
persistent and if I remove logging statements in my thread(I know I
should have made logging code thread safe), everything seems to work
out fine.

Thanks a zillion 
Chandan

0
maverick909
3/7/2005 3:45:57 PM
Suddenly, maverick909 sprang forth and uttered these pithy words:
> Well that guy was me. DDE had worked pretty well but it dint use to


Unfortunately, multi-thread (and less extent, multi-process) programming 
generally isn't very forgiving. You do have to learn about quite a few 
concepts to get it right. On top of that, I don't think you quite got 
the idea of PM programming, which is another somewhat tricky topic at 
the low level.
-- 
aaronl at consultant dot com 
For every expert, there is an equal and 
opposite expert. - Arthur C. Clarke
0
Aaron
3/8/2005 10:56:56 AM
Not even the Firefox developers understand multithreading...

On Tue, 8 Mar 2005 23:56:56 +1300, Aaron Lawrence wrote:

:>Suddenly, maverick909 sprang forth and uttered these pithy words:
:>> Well that guy was me. DDE had worked pretty well but it dint use to
:>
:>
:>Unfortunately, multi-thread (and less extent, multi-process) programming 
:>generally isn't very forgiving. You do have to learn about quite a few 
:>concepts to get it right. On top of that, I don't think you quite got 
:>the idea of PM programming, which is another somewhat tricky topic at 
:>the low level.
:>-- 
:>aaronl at consultant dot com 
:>For every expert, there is an equal and 
:>opposite expert. - Arthur C. Clarke



0
Hakan
3/8/2005 3:59:07 PM
Hakan turpitued:
>Not even the Firefox developers understand multithreading...

Amen, brother!  At present I'm preparing a review of Thunderbird,
and I keep discovering things being done in the foreground that
should have been put into a different thread.  I haven't had the
courage to look at the source code, but something is certainly
wrong with the top-level design.  And that's for a program that is,
on the whole, one of the better applications I've used.

Part of the problem, I think, is that student programmers get a lot
of their programming experience on Linux, and Linux didn't (until
recently?) have proper support for lightweight threads.  As a
result, those programmers are not developing the sort of mindset
that is needed to cope with more modern operating systems.  The
Windows-trained programmers are even worse, since many of them still
seem to be mentally stuck in the days of "cooperative multasking".

-- 
Peter Moylan                 peter at ee dot newcastle dot edu dot au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)
0
peter
3/8/2005 10:40:17 PM
Peter Moylan wrote:

> Part of the problem, I think, is that student programmers get a lot
> of their programming experience on Linux, and Linux didn't (until
> recently?) have proper support for lightweight threads.  
 >
  Unfortunately true. It is only the 2.6 Linux kernel that has decent 
thread support. The support in 2.4 and before is a horrible hack and far 
too many things just don't work right with threads (notably signals). 
Until 2.6 kernels, threads within a process only shared virtual memory 
and file handles, but not a number of other resources.

  This is pretty ridiculous in light of the fact that OS/2 had IMO 
"proper" thread implementation ever since 1.0 (1987) and Win32 since NT 
3.1 (1993). UNIX systems existed without tread support for a long time 
so programmers wrote single-threaded apps instead, with complex inner 
loops and non-blocking I/O.

  See 
http://homepages.tesco.net/~J.deBoynePollard/FGA/linux-thread-problems.html

which is not uptodate but accurately describes the problems with 
threading in Linux prior to 2.6 kernels.

  FWIW, I find that debugging threaded code in Linux is a major PITA, 
even with the latest kernels and gdb. More often than not it just plain 
doesn't work. But then the Linux people don't seem to believe in 
debugging and debuggers, so maybe this isn't so surprising.


          Michal

0
Michal
3/9/2005 1:32:27 AM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek 
<MichalN@scitechsoft.com>], who wrote in article <LmsXd.7335$DW.4279@newssvr17.news.prodigy.com>:
> thread support. The support in 2.4 and before is a horrible hack and far 
> too many things just don't work right with threads (notably signals). 
....
>   This is pretty ridiculous in light of the fact that OS/2 had IMO 
> "proper" thread implementation ever since 1.0 (1987)

Do not know...  Using your own cryteria, on OS/2 in 2005 thread
support is not good enough, since "signals" do not work with threads.
Similarly, I suspect that the crucial thing of getting the registers
of another thread is not supported (if this other thread happens to be
in a ring!=3 - due to 3-ring structure of OS/2 as opposed to 2-ring
structure of most of other OSes).

[Hmm, I may be ready to reconsider the second objection; there are
several crucial things which I do not know: can a suspended thread be
suspended in ring=2?  If yes - are the returned registers refering to
the state in ring=2, or to the when-return-to-ring-3 state?]

> UNIX systems existed without tread support for a long time 
> so programmers wrote single-threaded apps instead, with complex inner 
> loops and non-blocking I/O.

Here also your observation is not 100% on target.  There are *many*
situations when the added complexity of non-blocking I/O is much less
than inherent complexity of dealing with multi-threaded mindset...

Yours,
Ilya
0
Ilya
3/9/2005 4:29:16 AM
On 8 Mar 2005 22:40:17 GMT, Peter Moylan wrote:

:>Hakan turpitued:
:>>Not even the Firefox developers understand multithreading...
:>
:>Amen, brother!  At present I'm preparing a review of Thunderbird,
:>and I keep discovering things being done in the foreground that
:>should have been put into a different thread.  I haven't had the
:>courage to look at the source code, but something is certainly
:>wrong with the top-level design.  And that's for a program that is,
:>on the whole, one of the better applications I've used.
:>
:>Part of the problem, I think, is that student programmers get a lot
:>of their programming experience on Linux, and Linux didn't (until
:>recently?) have proper support for lightweight threads.  As a
:>result, those programmers are not developing the sort of mindset
:>that is needed to cope with more modern operating systems.  The
:>Windows-trained programmers are even worse, since many of them still
:>seem to be mentally stuck in the days of "cooperative multasking".
:>
:>-- 
:>Peter Moylan                 peter at ee dot newcastle dot edu dot au
:>http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)

Peter,

I got a very cool reception to my complaint when I aired it in the Mozilla
forum and I believe it is because: (1) the Mozilla team thinks it is the
best; and (2) they probably test the application on very fast computers which
masks some of the issues.

Some of issues in Firefox 1.0 are: (1) the application loses internal
messages when busy; (2) it ties up the system while opening "many" tabs
simultaneously in the same window; (3) "preparing" a page to be printed ties
up the system; (4) laying out a very long, complex page ties up the system;
(5) if one of the tabs is busy running a ticker (don't know if it is
Javascript) it compromises the ability to open and use a file dialog window. 
All very obvious if they had bothered exercising the application properly. 
All this on a 4-way SMP system...

Hakan


0
Hakan
3/9/2005 4:46:38 PM
Ilya Zakharevich wrote:

> Do not know...  Using your own cryteria, on OS/2 in 2005 thread
> support is not good enough, since "signals" do not work with threads.
 >
  But OS/2 uses exceptions, not signals ;)

> Similarly, I suspect that the crucial thing of getting the registers
> of another thread is not supported (if this other thread happens to be
> in a ring!=3 - due to 3-ring structure of OS/2 as opposed to 2-ring
> structure of most of other OSes).
> 
  I honestly don't understand how that is "crucial" unless you're 
writing a debugger. How do you get the registers of another thread with 
pthreads anyway?

> Here also your observation is not 100% on target.  There are *many*
> situations when the added complexity of non-blocking I/O is much less
> than inherent complexity of dealing with multi-threaded mindset...
> 
  Depends on the situation. I find that designing multi-threaded code is 
often easier, because it allows you to partition the code into 
self-contained threads.


         Michal

0
Michal
3/9/2005 6:55:47 PM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek 
<MichalN@scitechsoft.com>], who wrote in article <TEHXd.1943$ZB6.692@newssvr19.news.prodigy.com>:
> Ilya Zakharevich wrote:
> 
> > Do not know...  Using your own cryteria, on OS/2 in 2005 thread
> > support is not good enough, since "signals" do not work with threads.

>   But OS/2 uses exceptions, not signals ;)

Are we going to reduce an important question to discussion of
different lexicons on different OSes?

> > Similarly, I suspect that the crucial thing of getting the registers
> > of another thread is not supported (if this other thread happens to be
> > in a ring!=3 - due to 3-ring structure of OS/2 as opposed to 2-ring
> > structure of most of other OSes).

>   I honestly don't understand how that is "crucial" unless you're 
> writing a debugger.

Garbage collection.  To perform it, you need to inspect the stack of
all the threads.  And if ESP which an API returns is for a Ring-2
stack, you are sol...

> How do you get the registers of another thread with 
> pthreads anyway?

I do know; all I know is that multithread garbage collection is not
very hard - on all architechtures EXCEPT OS/2.  [But personally, I
hate pthreads API - the simple things are not simple; but it may be
that the functionality is a strict SUPERSET of what OS/2 can provide...]

> > Here also your observation is not 100% on target.  There are *many*
> > situations when the added complexity of non-blocking I/O is much less
> > than inherent complexity of dealing with multi-threaded mindset...

>   Depends on the situation. I find that designing multi-threaded code is 
> often easier, because it allows you to partition the code into 
> self-contained threads.

But as you have shown in previous discussions, you do not always try
to make your code 100%-proof against race conditions or deadlocks.
Having 99%-percent working design is much easier than having *the
design* to be 100%-robust.  (Of course, the implementation is always
wanting improvement. ;-)

[In particular, Scott sometimes suggests that semaphores on OS/2 are
probabilistic only - at least those used in the kernel???]

Yours,
Ilya

P.S.  Another important misfeature of OS/2 threading system (I know
of) is a race condition in fetching the result after asyncroneous
DosExecPgm().  E.g., if after starting an asyncroneous child you need

  a) Have some work done;

  b) Meanwhile if the child ends, have some work started;

  c) If, after "a" finishes, the condition in "b" did not occur, kill
     the child. 

Due to immediate PID reuse (after PID wrap), it could have been that
"b" fetched the return code of the program, but "c" did not notice
that the code was fetched.  If, meanwhile, OS reused the PID, the
kill() will kill a wrong process.

[Technically, the problem is that PID is reused immediately after
DosReadQueue() returns; but the kernel has no knowledge that the
application had a chance to *process* the result of the call.
Essentially, an "ACK" is missing from the protocol.

I discussed this with Scott several years ago, and he said he will
think about possible fixes (I proposed several).  Do not know whether
it resulted in anything...]
0
Ilya
3/10/2005 12:36:06 AM
Ilya Zakharevich wrote:

> Are we going to reduce an important question to discussion of
> different lexicons on different OSes?
> 
  The fact is that different OSes use different mechanisms to achieve 
similar objectives. Trying to shoehorn certain way of doing things onto 
"foreign" OSes is fraught with peril.

>>  I honestly don't understand how that is "crucial" unless you're 
>>writing a debugger.
> 
> Garbage collection.
 >
  Oh. Not something I need or want.

>>How do you get the registers of another thread with 
>>pthreads anyway?
> 
> I do know; 
 >
  Did you mean "don't know"?

> all I know is that multithread garbage collection is not
> very hard - on all architechtures EXCEPT OS/2.  [But personally, I
> hate pthreads API - the simple things are not simple; but it may be
> that the functionality is a strict SUPERSET of what OS/2 can provide...]
> 
  The pthreads API is designed to be very portable, although it's true 
that it does seem to be more complicated than it needs to be. Given how 
hard it is to get at process/thread registers in UNIX in general, I'd be 
shocked if there was an easy way to do it with pthreads. But if you know 
of one, I'm be interested in it!

> Having 99%-percent working design is much easier than having *the
> design* to be 100%-robust.  (Of course, the implementation is always
> wanting improvement. ;-)
> 
  The question then becomes - how do you know that you have a 100% 
robust design?

> P.S.  Another important misfeature of OS/2 threading system (I know
> of) is a race condition in fetching the result after asyncroneous
> DosExecPgm().
 >
  I don't see what this has to do with threading. It is a flaw in 
process management and will affect single threaded processes just as 
well as multi threaded; in fact using threading will help because then 
there's less need for separate processes ;)


          Michal

0
Michal
3/10/2005 1:06:42 AM
Hi,

Seems like I have got a lot to learn, where should i start picking up
PM multithreading concepts. Any good books? Although I dont know i how
helpful learning about PM will be in the long run. OS2 is a dying OS.
Windows systems let you be a fool most of the times.

Regards,
Chandan

0
maverick909
3/10/2005 3:26:55 AM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek 
<MichalN@scitechsoft.com>], who wrote in article <C4NXd.7943$DW.7226@newssvr17.news.prodigy.com>:
> > Are we going to reduce an important question to discussion of
> > different lexicons on different OSes?

>   The fact is that different OSes use different mechanisms to achieve 
> similar objectives. Trying to shoehorn certain way of doing things onto 
> "foreign" OSes is fraught with peril.

"Similar objectives" is the keyword.  You chastise (older) Linux that
it can't do something, when on (IYO, better in this regard even in
'89) OS/2 you can't do the "similar objective" even now.

> >>  I honestly don't understand how that is "crucial" unless you're 
> >>writing a debugger.

> > Garbage collection.

>   Oh. Not something I need or want.

You do not need (or ever expect to need) Java?  (I do not run it, but
it has a chance to become useful some time in the future.)  Do not
know about ECMAScript, most probably it also needs garbage
collection.  Do you use Mozilla/Netscape/Firefox?

> > I do know; 
>  >
>   Did you mean "don't know"?

Sorry for sloppy copyediting, you are of course correct.

> > Having 99%-percent working design is much easier than having *the
> > design* to be 100%-robust.  (Of course, the implementation is always
> > wanting improvement. ;-)

>   The question then becomes - how do you know that you have a 100% 
> robust design?

Some people run the design through a theorem-prover; you need a
special language which is good enough to compile AND to feed to a
prover.  But if you manage to find a simple enough solution, it may be
feasible to run through the state diagram with a piece of paper and
pencil.  Some people prove theorems without computers.  ;-)

> > P.S.  Another important misfeature of OS/2 threading system (I know
> > of) is a race condition in fetching the result after asyncroneous
> > DosExecPgm().

>   I don't see what this has to do with threading. It is a flaw in 
> process management and will affect single threaded processes just as 
> well as multi threaded; in fact using threading will help because then 
> there's less need for separate processes ;)

a) Threading can't decrease need for separate processes.  These are
   different tools with very different domains of applicability.
   [Sometimes, however, processes are used as poor man substitutions
   for threads, or visa versa; then your observation is applicable.]

b) I could not find a vulnerability scenario involving a single
   thread.  Either DosReadQueue() returned the exit code, or not; you
   always know which of these possibilities holds.

   If it did not return the exit code, the PID is not reused ("zombie"
   state); so you are safe to kill().  If it did return, the PID may
   be reused, but you have enough info to NOT kill().

Hope this helps,
Ilya
0
Ilya
3/10/2005 8:45:09 AM
On Thu, 10 Mar 2005 03:26:55 UTC, "maverick909" 
<gupta.chandan@gmail.com> wrote:

> Hi,
> 
> Seems like I have got a lot to learn, where should i start picking up
> PM multithreading concepts. Any good books? Although I dont know i how
> helpful learning about PM will be in the long run. OS2 is a dying OS.
> Windows systems let you be a fool most of the times.

Control Program Programming Guide and Reference
Programming Guide and Reference Addendum
Presentation Manager Programming Guide and Reference
SG24-4640-00 The OS/2 Debugging Handbook
System Objcet Model Programming Guide
OS/2 Server Family programming Reference
TCP/IP Version 4.21 Programming Reference
Tools Reference
Using Your Toolkit
WorkPlaceShell Programming Guide
WorkPlaceShell programming Reference
Fehler-/Pr�fprotokollprogramm - Hilfe
C Library Reference


All in toolkt452.zip (eCS CD#2). The toolkit contains samples too.

When you use GCC you may read too
emx 0.9d Application Developers Guide
emx 0.9d C Library Reference
User's Guide to the emx Runtime
Help for pmgdb
For that you would have installed the emx developer kit instead the 
pure runtime.

You would use NewView to read the books as it makes some things much 
easier as the orgiginal view.

OS/2's multithreading is designed to work with one or multiple CPUs. 
The only difference is that running multiple threads on a single CPU 
seems in parallel and on multiple CPUs it can (must not) real 
parallel, depending on the number of threads and CPUs. 

So designing threads requires to thing in real parallel work.

CLOCKSCALE=x in config.sys defines the time slice a thread can use:
x = 4:  4ms
    3:  8ms
    2: 16ms
    1: 32ms (same as if CLOCKSCALE not given.)

clockscale requires a kernel newer than in MCP1 GA (WARP4.51/eCS 1.0).

process management on most OSes is based on processes, so pthreads is 
threads in user space - OS/2 threads are the base of OS/2 process 
management.

Single threaded applications are running one thread under the cover of
the process - multithreaded applications runs mutliple threads under 
the the same cover.

Attention: you needs different libraries for multithreaded 
applications than for single threaded ones. That would be defined on 
the linker flags (on the compiler).

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/10/2005 10:22:31 AM
Ilya Zakharevich wrote:

> "Similar objectives" is the keyword.  You chastise (older) Linux that
> it can't do something, when on (IYO, better in this regard even in
> '89) OS/2 you can't do the "similar objective" even now.
> 
  I chastise Linux for not being able to do (at least until fairly 
recently) something that other UNIX systems have been able to do for a 
long time.

> You do not need (or ever expect to need) Java?  (I do not run it, but
> it has a chance to become useful some time in the future.)  Do not
> know about ECMAScript, most probably it also needs garbage
> collection.  Do you use Mozilla/Netscape/Firefox?
> 
  Java has its own tightly controlled runtime environment. I never heard 
anyone say that garbage collection can't be done in Java on OS/2. Same 
goes for JavaScript.

> Some people run the design through a theorem-prover; you need a
> special language which is good enough to compile AND to feed to a
> prover.  But if you manage to find a simple enough solution, it may be
> feasible to run through the state diagram with a piece of paper and
> pencil.  Some people prove theorems without computers.  ;-)
> 
  The catch is that you often don't know if your design took into 
account *every* possibility, and by definition you can never know that 
if the problem is complex. Of course eg. the fact that some code has 
been functioning flawlessly for 10 years is no proof that it's 100% 
correct either.

> b) I could not find a vulnerability scenario involving a single
>    thread.  
 >
  But can you _prove_ that there isn't one?


           Michal

0
Michal
3/10/2005 7:30:17 PM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Michal Necasek 
<MichalN@scitechsoft.com>], who wrote in article <df1Yd.11626$CC6.1095@newssvr31.news.prodigy.com>:
>   I chastise Linux for not being able to do (at least until fairly 
> recently) something that other UNIX systems have been able to do for a 
> long time.

Well, this is not what was written in your original post...

> > You do not need (or ever expect to need) Java?  (I do not run it, but
> > it has a chance to become useful some time in the future.)  Do not
> > know about ECMAScript, most probably it also needs garbage
> > collection.  Do you use Mozilla/Netscape/Firefox?

>   Java has its own tightly controlled runtime environment. I never heard 
> anyone say that garbage collection can't be done in Java on OS/2. Same 
> goes for JavaScript.

I did not say "it can't be done".  One can preserve your registers in
a well-known location on any call which may call Ring2 code; or do not
trust ESP at all, and check *all the stack* (from stack-top to
stack-bottom) all the time.

But it can't be done as efficiently as on other systems, and/or using
the same algorithms as on other systems.

> > Some people run the design through a theorem-prover; you need a
> > special language which is good enough to compile AND to feed to a
> > prover.  But if you manage to find a simple enough solution, it may be
> > feasible to run through the state diagram with a piece of paper and
> > pencil.  Some people prove theorems without computers.  ;-)

>   The catch is that you often don't know if your design took into 
> account *every* possibility

Proving theorems is not always a very easy job.

> and by definition you can never know that if the problem is complex.

This is why threading API which allow many problems to have simple
solutions are so important...

> > b) I could not find a vulnerability scenario involving a single
> >    thread.  

>   But can you _prove_ that there isn't one?

Are you joking?  There is no trustworthy docs of OS/2 APIs!  But if
you trust what Scott says time to time, then what you removed from my
message was a proof...

Hope this helps,
Ilya
0
Ilya
3/10/2005 9:12:39 PM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Herbert Rosenau
<os2guy@pc-rosenau.de>], who wrote in article <wmzsGguTDN6N-pn2-uC2FhgxdDVmv@URANUS1.DV-ROSENAU.DE>:
> CLOCKSCALE=x in config.sys defines the time slice a thread can use:
> x = 4:  4ms
>     3:  8ms
>     2: 16ms
>     1: 32ms (same as if CLOCKSCALE not given.)

IFAIK, CLOCKSCALE affects only time-critical threads; the formula for
timeslice of these threads is 8ms/CLOCKSCALE (maybe clockscale should
be divisor of 8?).  The timeslice of other threads is always 32ms.

> process management on most OSes is based on processes, so pthreads is 
> threads in user space - OS/2 threads are the base of OS/2 process 
> management.

At least, this sentence is very confusing; most probably it is just
plain wrong.  pthreads on Unix use whatever implementation they want
(most advanced use combinations of user space threads and the kernel
threads).  pthreads on OS/2 may also use different implementations
(mine uses native threads).

Hope this helps,
Ilya
0
Ilya
3/10/2005 9:24:20 PM
On Thu, 10 Mar 2005 21:24:20 UTC,  Ilya Zakharevich 
<nospam-abuse@ilyaz.org> wrote:

> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Herbert Rosenau
> <os2guy@pc-rosenau.de>], who wrote in article <wmzsGguTDN6N-pn2-uC2FhgxdDVmv@URANUS1.DV-ROSENAU.DE>:
> > CLOCKSCALE=x in config.sys defines the time slice a thread can use:
> > x = 4:  4ms
> >     3:  8ms
> >     2: 16ms
> >     1: 32ms (same as if CLOCKSCALE not given.)
> 
> IFAIK, CLOCKSCALE affects only time-critical threads; the formula for
> timeslice of these threads is 8ms/CLOCKSCALE (maybe clockscale should
> be divisor of 8?).  The timeslice of other threads is always 32ms.

That is gone since Scott has implemented clockscale in the kernel. 
clockscale was introduced to tune up anything on more modern CPUs as 
32ms is too long on that. It is related on any application.
 
> > process management on most OSes is based on processes, so pthreads is 
> > threads in user space - OS/2 threads are the base of OS/2 process 
> > management.
> 
> At least, this sentence is very confusing; most probably it is just
> plain wrong.  pthreads on Unix use whatever implementation they want
> (most advanced use combinations of user space threads and the kernel
> threads).  pthreads on OS/2 may also use different implementations
> (mine uses native threads).

Unix knows nothing about threads.
Linux prior kernel 2.6.x knows nothing about threads.
Posix has phreads to give an application the possibility to use 
multiple threads even as the kernel knows nothing about.
I'm truly not informed yet how the state about kernel threads is on 
the most current kernel in linux yet.

But OS/2 is designed on threads instead processes since its first 
days. It is nice to know that your implementation of pthreads on OS/2 
is based on kernel threads.

It looks like your code is well hidden somewhere.

As WEB master of ecomstation.de it would be of interest to get be 
informed about anything you has written for OS/2 and where it can be 
downloaded from. I would like to publish any information on that page 
you can give me (plain text is enough, HTML (content only) would be 
nice. Translation to german is no problem. You may use simply the 
reply button on this artikle or send to info@ecomstation.de. Any side 
information (copyright, author...) will be respected as ecomstation.de
is designed to support ecomstation and its users in any possible way 
instead to make out with such things.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/10/2005 10:55:24 PM
Herbert Rosenau wrote:

> Unix knows nothing about threads.
 >
  Bullshit. Check the docs for Solaris, AIX etc. And please stop 
spreading misinformation (although I realize this request will fall on 
deaf ears).

> Linux prior kernel 2.6.x knows nothing about threads.
 >
  Nonsense. Check clone() man page on 2.4. What do you think clone() 
does? The thread support prior to 2.6 sucks big time but it is there.


        Michal

0
Michal
3/10/2005 11:02:12 PM
On Wed, 9 Mar 2005 16:46:38 UTC, "Hakan" wrote:

> On 8 Mar 2005 22:40:17 GMT, Peter Moylan wrote:
> 
> :>Hakan turpitued:
> :>>Not even the Firefox developers understand multithreading...

Of course, none of the Firefox developers uses OS/2 ...

> :>At present I'm preparing a review of Thunderbird,
> :>and I keep discovering things being done in the foreground that
> :>should have been put into a different thread.

.... same goes for Thunderbird. And all Mozilla apps are cross-platform 
which is probably the main reason why it cannot easily use threading the
way better OS/2 apps do. Just don't forget: if it weren't cross-platform
and if the IBMers and some others hadn't invested a huge amount of time 
we would be left without a browser on OS/2!

> I got a very cool reception to my complaint when I aired it in the Mozilla
> forum and I believe it is because: 

I know it is pointless to try to argue with you, but the "cool 
reception" was mainly because you thought you knew everything about OS/2
threading but couldn't really demonstrate the problems. Rich Walsh 
actually wrote a long and detailed reply which you obviously never tried
to understand.

> (2) they probably test the application on very fast computers which
> masks some of the issues.

I am not really part of the "Mozilla team" (I have just submitted some 
patches which everyone is welcome to do!), but I used and from time to 
time still try it on a P166. It runs a lot slower than on my main 
machine but it works just as well!

> Some of issues in Firefox 1.0 are

Well, I am not really a FF user (I use the browser of the suite).

> (2) it ties up the system while opening "many" tabssimultaneously in the same window;

Not sure what you mean by "tie up", but of course it uses a lot of CPU 
time when opening lots of tabs. How could it _not_ do that?

> (3) "preparing" a page to be printed ties up the system;
> (4) laying out a very long, complex page ties up the system;

It doesn't "tie up the system" but it certainly takes a lot of CPU and 
takes longer than on other platforms. That is indeed a problem, see 
<http://bugzilla.mozilla.org/show_bug.cgi?id=258136>. I very much 
welcome any suggestions on how to debug this, given that there is no 
working profiler for GCC code.

> All very obvious if they had bothered exercising the application properly. 
> All this on a 4-way SMP system...

Please make it better. A good start would be to look at the os2embed.exe
sample that is shipped with Mozilla. The sources of that are freely 
available and can be used by anyone (under MPL license at least) to 
start embedding the Mozilla/Gecko rendering engine into a true OS/2 
application with "real" OS/2 threading.
-- 
Greetings,                         Please reply in newsgroup, I rarely
   Peter.                            read emails to pweilba@gwdg.de...
0
Peter
3/11/2005 1:04:15 AM
On 11 Mar 2005 01:04:15 GMT, Peter Weilbacher wrote:

:>On Wed, 9 Mar 2005 16:46:38 UTC, "Hakan" wrote:
:>
:>> On 8 Mar 2005 22:40:17 GMT, Peter Moylan wrote:
:>> 
:>> :>Hakan turpitued:
:>> :>>Not even the Firefox developers understand multithreading...
:>
:>Of course, none of the Firefox developers uses OS/2 ...
:>
:>> :>At present I'm preparing a review of Thunderbird,
:>> :>and I keep discovering things being done in the foreground that
:>> :>should have been put into a different thread.
:>
:>.... same goes for Thunderbird. And all Mozilla apps are cross-platform 
:>which is probably the main reason why it cannot easily use threading the
:>way better OS/2 apps do. Just don't forget: if it weren't cross-platform
:>and if the IBMers and some others hadn't invested a huge amount of time 
:>we would be left without a browser on OS/2!

Does not the Windows version suffer from the same design flaws?  If so, it
has nothing to do with OS/2.

:>> I got a very cool reception to my complaint when I aired it in the Mozilla
:>> forum and I believe it is because: 
:>
:>I know it is pointless to try to argue with you, but the "cool 
:>reception" was mainly because you thought you knew everything about OS/2
:>threading but couldn't really demonstrate the problems. Rich Walsh 
:>actually wrote a long and detailed reply which you obviously never tried
:>to understand.

Why are you resorting to an ad hominem attack on me?  I am very well aware of
Rich's reply and I have the deepest respect for him as a WPS developer -- I
just didn't agree fully with his reply, where, if I remember correctly, he
actually half agreed with me.  I actually do write multi-threaded PM
applications for my own use and am not a novice.

:>> (2) they probably test the application on very fast computers which
:>> masks some of the issues.
:>
:>I am not really part of the "Mozilla team" (I have just submitted some 
:>patches which everyone is welcome to do!), but I used and from time to 
:>time still try it on a P166. It runs a lot slower than on my main 
:>machine but it works just as well!
:>
:>> Some of issues in Firefox 1.0 are
:>
:>Well, I am not really a FF user (I use the browser of the suite).
:>
:>> (2) it ties up the system while opening "many" tabssimultaneously in the same window;
:>
:>Not sure what you mean by "tie up", but of course it uses a lot of CPU 
:>time when opening lots of tabs. How could it _not_ do that?

I used tie up to mean that the rest of the system is not responding
"promptly."  It could avoid doing that by not performing that action in the
main thread.

:>> (3) "preparing" a page to be printed ties up the system;
:>> (4) laying out a very long, complex page ties up the system;

Yes, it does indeed tie up the system and prevents the WPS from responding
"quickly" while performing any of the actions I listed (and you left some out
in the reply of yours.)

:>It doesn't "tie up the system" but it certainly takes a lot of CPU and 
:>takes longer than on other platforms. That is indeed a problem, see 
:><http://bugzilla.mozilla.org/show_bug.cgi?id=258136>. I very much 
:>welcome any suggestions on how to debug this, given that there is no 
:>working profiler for GCC code.
:>
:>> All very obvious if they had bothered exercising the application properly. 
:>> All this on a 4-way SMP system...
:>
:>Please make it better. A good start would be to look at the os2embed.exe
:>sample that is shipped with Mozilla. The sources of that are freely 
:>available and can be used by anyone (under MPL license at least) to 
:>start embedding the Mozilla/Gecko rendering engine into a true OS/2 
:>application with "real" OS/2 threading.

No, I am not about to rewrite it myself and I obviously do not have to do
that to be able to point out design flaws or problems.  Further, I am not the
first, or only person, to note those flaws.

:>-- 
:>Greetings,                         Please reply in newsgroup, I rarely
:>   Peter.                            read emails to pweilba@gwdg.de...



0
Hakan
3/11/2005 4:03:23 AM
Hakan wrote:
> No, I am not about to rewrite it myself and I obviously do not have to do
> that to be able to point out design flaws or problems.  Further, I am not the
> first, or only person, to note those flaws.
> 
  You didn't pay anything for Mozilla and you're not prepared to expend 
any effort on improving it. Why the hell should the Mozilla developers 
care about what you say then?


          Michal

0
Michal
3/11/2005 4:41:01 AM
On Fri, 11 Mar 2005 04:41:01 GMT, Michal Necasek wrote:

:>Hakan wrote:
:>> No, I am not about to rewrite it myself and I obviously do not have to do
:>> that to be able to point out design flaws or problems.  Further, I am not the
:>> first, or only person, to note those flaws.
:>> 
:>  You didn't pay anything for Mozilla and you're not prepared to expend 
:>any effort on improving it. Why the hell should the Mozilla developers 
:>care about what you say then?

If my comments are correct, why should they not?  Are they not interested in
improving the product?  Again, I am not the first, nor the only, person to
point out the design flaws.

:>
:>
:>          Michal
:>



0
Hakan
3/11/2005 5:12:09 AM
Hakan wrote:

> If my comments are correct, why should they not?  Are they not interested in
> improving the product?  
 >
  Are they running OS/2? If not, why should they care? Obviously they 
feel it's good enough for them.

> Again, I am not the first, nor the only, person to point out the design flaws.
> 
  So? Please realize that the Mozilla developers are not obligated to do 
*anything* for you, of for five million complainers. If you're unhappy 
with their work, don't use their software!


          Michal

0
Michal
3/11/2005 5:30:04 AM
On Thu, 10 Mar 2005 23:02:12 UTC, Michal Necasek 
<MichalN@scitechsoft.com> wrote:

> Herbert Rosenau wrote:
> 
> > Unix knows nothing about threads.
>  >
>   Bullshit. Check the docs for Solaris, AIX etc. And please stop 
> spreading misinformation (although I realize this request will fall on 
> deaf ears).
> 
> > Linux prior kernel 2.6.x knows nothing about threads.
>  >
>   Nonsense. Check clone() man page on 2.4. What do you think clone() 
> does? The thread support prior to 2.6 sucks big time but it is there.

I know of POSIX! But that is an extension in userspace, has nothing to
do with the kernel.

clone() is nothing than clone a process to another process - has 
nothing to do with threading.
Would you be able to access a ny data inside the process that was the 
source of clone from the cloded one? Would be able to access any data 
in the proces the clond one was createn from?

multithreading means NOT multiprocessing.
multiprocessing means NOT multithreading. 

Mutlithreading is access any data of any thread inside the same 
process directly without each and any interprocess communication 
because all threads are hosted inside the same process, having exactly
the same process id but using different thread IDs.

Unix is multiprocessed - single threaded.
Linux is multiprocessed - single threaded before kernel 2.6.x
OS/2 is mutiprocessed - multithreaded.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/11/2005 10:33:20 AM
Hakan wrote:
> On 11 Mar 2005 01:04:15 GMT, Peter Weilbacher wrote:
> 
> :>Just don't forget: if it weren't cross-platform
> :>and if the IBMers and some others hadn't invested a huge amount
> :>of time we would be left without a browser on OS/2!
> 
> Does not the Windows version suffer from the same design flaws?  If 
> so, it has nothing to do with OS/2.

You can run it on Windows on your SMP system and report. But I guess it
is not really a "design flaw" but a necessary evil because of the
cross-platform nature. Of course one could change the architecture of
the whole application and put a whole lot of #ifdef OS2's in the source
to optimize it for OS/2 but there are no resources for this, especially
since IBM dropped out of the game. You obviously did not volunteer, and
I don't feel compelled to do anything because it works fine on my system
and I don't have enough knowledge anyway.

> :>Not sure what you mean by "tie up", but of course it uses a lot of 
> :>CPU time when opening lots of tabs. How could it _not_ do that?
> 
> I used tie up to mean that the rest of the system is not responding 
> "promptly."  It could avoid doing that by not performing that action 
> in the main thread.

So you are saying that _Firefox_ is tied up, not the system? Because if
one thread is using a lot of CPU it can hardly tie up the whole system,
especially on your 4xSMP system (it doesn't do that on my P166), unless
it blocks the message queue and if that would happen, OS/2 would still
be able to switch and just not repaint that window. Or are you using an
OS/2 version from before the SIQ fix?

> :>but it certainly takes a lot of CPU and takes longer than on other
> :>platforms. That is indeed a problem, see
> :><http://bugzilla.mozilla.org/show_bug.cgi?id=258136>. I very 
> :>much welcome any suggestions on how to debug this

Any ideas?

> No, I am not about to rewrite it myself and I obviously do not have 
> to do that to be able to point out design flaws or problems. Further,
> I am not the first, or only person, to note those flaws.

No, but as most other people you are not offering any help or concrete
hints how to achieve anything, and the tone of your postings suggests,
that you don't want to help the situation just boast about how bad an
app is that nobody forces you to use.
-- 
Gr��e von
   Peter.
0
Peter
3/11/2005 11:06:50 AM
Suddenly, maverick909 sprang forth and uttered these pithy words:
> Hi,
> 
> Seems like I have got a lot to learn, where should i start picking up
> PM multithreading concepts. 

There aren't many :)

1) You can't multithread PM code except
2) you can multithread drawing

so you can't call any PM controls etc from another thread.

Generally this means posting messages back to your main window to tell 
it to show results/progress.


-- 
aaronl at consultant dot com 
For every expert, there is an equal and 
opposite expert. - Arthur C. Clarke
0
Aaron
3/11/2005 3:59:29 PM
Suddenly, Michal Necasek sprang forth and uttered these pithy words:
>   So? Please realize that the Mozilla developers are not obligated to do 
> *anything* for you, of for five million complainers. If you're unhappy 
> with their work, don't use their software!

Michal,

although I broadly agree with you in this case, this is a common but 
redundant argument. 

Not everyone can be a programmer, but everyone can contribute 
observations about problems, even major ones. 

They just can't *demand* to have them fixed.

I don't know that Hakan is demanding that they be fixed.

-- 
aaronl at consultant dot com 
For every expert, there is an equal and 
opposite expert. - Arthur C. Clarke
0
Aaron
3/11/2005 4:02:40 PM
On Fri, 11 Mar 2005 05:30:04 GMT, Michal Necasek wrote:

:>Hakan wrote:
:>
:>> If my comments are correct, why should they not?  Are they not interested in
:>> improving the product?  
:> >
:>  Are they running OS/2? If not, why should they care? Obviously they 
:>feel it's good enough for them.
:>
:>> Again, I am not the first, nor the only, person to point out the design flaws.
:>> 
:>  So? Please realize that the Mozilla developers are not obligated to do 
:>*anything* for you, of for five million complainers. If you're unhappy 
:>with their work, don't use their software!

Who said they were obligated to do anything?  I pointed out design
shortcomings and others agree.  Period.

:>
:>
:>          Michal
:>



0
Hakan
3/11/2005 4:37:35 PM
On Fri, 11 Mar 2005 11:06:50 +0000, Peter Weilbacher wrote:

:>Hakan wrote:
:>> On 11 Mar 2005 01:04:15 GMT, Peter Weilbacher wrote:
:>> 
:>> :>Just don't forget: if it weren't cross-platform
:>> :>and if the IBMers and some others hadn't invested a huge amount
:>> :>of time we would be left without a browser on OS/2!
:>> 
:>> Does not the Windows version suffer from the same design flaws?  If =

:>> so, it has nothing to do with OS/2.
:>
:>You can run it on Windows on your SMP system and report. But I guess i=
t
:>is not really a "design flaw" but a necessary evil because of the
:>cross-platform nature. Of course one could change the architecture of
:>the whole application and put a whole lot of #ifdef OS2's in the sourc=
e
:>to optimize it for OS/2 but there are no resources for this, especiall=
y
:>since IBM dropped out of the game. You obviously did not volunteer, an=
d
:>I don't feel compelled to do anything because it works fine on my syst=
em
:>and I don't have enough knowledge anyway.

I am not running Windows but your posting suggested this were OS/2 speci=
fic
design flaws.  I am merely inquiring whether the Windows version does no=
t
suffer from the design flaws.  Design flaws, by the way, have nothing to=
 do
with volunteering or not.  And, if as you say, you "don't have enough
knowledge anyway," why are you attacking me, the messager?

:>> :>Not sure what you mean by "tie up", but of course it uses a lot of=
 
:>> :>CPU time when opening lots of tabs. How could it _not_ do that?
:>> 
:>> I used tie up to mean that the rest of the system is not responding =

:>> "promptly."  It could avoid doing that by not performing that action=
 
:>> in the main thread.
:>
:>So you are saying that _Firefox_ is tied up, not the system? Because i=
f
:>one thread is using a lot of CPU it can hardly tie up the whole system=
,
:>especially on your 4xSMP system (it doesn't do that on my P166), unles=
s
:>it blocks the message queue and if that would happen, OS/2 would still=

:>be able to switch and just not repaint that window. Or are you using a=
n
:>OS/2 version from before the SIQ fix?

The system is tied up -- which I did say.

:>> :>but it certainly takes a lot of CPU and takes longer than on other=

:>> :>platforms. That is indeed a problem, see
:>> :><http://bugzilla.mozilla.org/show_bug.cgi?id=3D258136>. I very 
:>> :>much welcome any suggestions on how to debug this
:>
:>Any ideas?

Those were not my comments but belonged to somebody else.

:>> No, I am not about to rewrite it myself and I obviously do not have =

:>> to do that to be able to point out design flaws or problems. Further=
,
:>> I am not the first, or only person, to note those flaws.
:>
:>No, but as most other people you are not offering any help or concrete=

:>hints how to achieve anything, and the tone of your postings suggests,=

:>that you don't want to help the situation just boast about how bad an
:>app is that nobody forces you to use.

Pointing out design flaws does not require that I start rewriting the co=
de,
nor was I "boasting".

:>Gr=FC=DFe von
:>   Peter.





0
Hakan
3/11/2005 4:39:12 PM
Hakan wrote:

> why are you attacking me, the messager?

If you feel attacked by my posting so be it. That was not what I wanted
to achieve, but what do you expect when you start a discussion with a
rough tone like "the Mozilla team thinks it is the best".

> :>So you are saying that _Firefox_ is tied up, not the system? Because if
> :>one thread is using a lot of CPU it can hardly tie up the whole system,
> :>especially on your 4xSMP system (it doesn't do that on my P166), unless
> :>it blocks the message queue and if that would happen, OS/2 would still
> :>be able to switch and just not repaint that window. Or are you using an
> :>OS/2 version from before the SIQ fix?
> 
> The system is tied up -- which I did say.

Then please tell me how you think that is possible without generally
badmouthing Firefox or its threading model.

> :>> :>but it certainly takes a lot of CPU and takes longer than on other
> :>> :>platforms. That is indeed a problem, see
> :>> :><http://bugzilla.mozilla.org/show_bug.cgi?id=258136>. I very 
> :>> :>much welcome any suggestions on how to debug this
> :>
> :>Any ideas?
> 
> Those were not my comments but belonged to somebody else.

Yes, me. I am looking for help debugging the problem and solving the bug.
-- 
Gr��e von
   Peter.
0
Peter
3/11/2005 6:00:06 PM
Aaron Lawrence wrote:

> Not everyone can be a programmer, but everyone can contribute 
> observations about problems, even major ones. 
> 
  The people who are programmers however are free to listen to the 
observations and then not act on them. If the Mozilla developers 
considered this to be a major problem, I'm sure they'd have worked on 
it. But honestly, I don't know how anybody can expect in this day and 
age that anything associated with OS/2 is "major". We're probably very 
lucky that there's an OS/2 version at all, and that is only thanks to IBM.

> I don't know that Hakan is demanding that they be fixed.
> 
  Even if he was, demands would get him nowhere ;)

  He still has the wrong attitude. He's expecting that *someone else* 
will fix *his* problems while he is contributing nothing (and no, 
reporting problems doesn't count as a contribution compared to actually 
fixing something). Why he thinks that this someone else will want to do 
it is beyond me.


         Michal

0
Michal
3/11/2005 6:23:02 PM
Herbert Rosenau wrote:

> I know of POSIX! But that is an extension in userspace, has nothing to
> do with the kernel.
> 
  No, you don't know about POSIX and the above sentence proves it. POSIX 
is a standardized operating system interface and great many of the POSIX 
functions often *are* implemented in an OS kernel.

> clone() is nothing than clone a process to another process - has 
> nothing to do with threading.
 >
  Uhh right. Now please read up on fork() and compare it with clone().

> Would you be able to access a ny data inside the process that was the 
> source of clone from the cloded one? Would be able to access any data 
> in the proces the clond one was createn from?
> 
  Yes, of course. That's the whole point of clone().

> Unix is multiprocessed - single threaded.
> Linux is multiprocessed - single threaded before kernel 2.6.x
> OS/2 is mutiprocessed - multithreaded.
> 
  You just have no clue.


            Michal

0
Michal
3/11/2005 6:28:39 PM
On Fri, 11 Mar 2005 18:23:02 GMT, Michal Necasek wrote:

:>Aaron Lawrence wrote:
:>
:>> Not everyone can be a programmer, but everyone can contribute 
:>> observations about problems, even major ones. 
:>> 
:>  The people who are programmers however are free to listen to the 
:>observations and then not act on them. If the Mozilla developers 
:>considered this to be a major problem, I'm sure they'd have worked on 
:>it. But honestly, I don't know how anybody can expect in this day and 
:>age that anything associated with OS/2 is "major". We're probably very 
:>lucky that there's an OS/2 version at all, and that is only thanks to IBM.
:>
:>> I don't know that Hakan is demanding that they be fixed.
:>> 
:>  Even if he was, demands would get him nowhere ;)
:>
:>  He still has the wrong attitude. He's expecting that *someone else* 
:>will fix *his* problems while he is contributing nothing (and no, 
:>reporting problems doesn't count as a contribution compared to actually 
:>fixing something). Why he thinks that this someone else will want to do 
:>it is beyond me.

"I" have the wrong attitude? You seem to be personally offended by what I,
and others, consider design flaws in Firefox being pointed out.  Why are you
so defensive about this?  Did you write this particular piece of code or is
your reputation at stake?  If not, please relax.

:>
:>
:>         Michal
:>



0
Hakan
3/11/2005 7:59:26 PM
On Fri, 11 Mar 2005 18:00:06 +0000, Peter Weilbacher wrote:

:>Hakan wrote:
:>
:>> why are you attacking me, the messager?
:>
:>If you feel attacked by my posting so be it. That was not what I wante=
d
:>to achieve, but what do you expect when you start a discussion with a
:>rough tone like "the Mozilla team thinks it is the best".
:>
:>> :>So you are saying that _Firefox_ is tied up, not the system? Becau=
se if
:>> :>one thread is using a lot of CPU it can hardly tie up the whole sy=
stem,
:>> :>especially on your 4xSMP system (it doesn't do that on my P166), u=
nless
:>> :>it blocks the message queue and if that would happen, OS/2 would s=
till
:>> :>be able to switch and just not repaint that window. Or are you usi=
ng an
:>> :>OS/2 version from before the SIQ fix?
:>> 
:>> The system is tied up -- which I did say.
:>
:>Then please tell me how you think that is possible without generally
:>badmouthing Firefox or its threading model.

By doing too much of the work in the main thread and not adhering to the=
 1/10
second rule (or similar) -- on a "slow" computer where such things are m=
ore
likely to become noticeable.  This is indeed an application-specific des=
ign
issue.

:>> :>> :>but it certainly takes a lot of CPU and takes longer than on o=
ther
:>> :>> :>platforms. That is indeed a problem, see
:>> :>> :><http://bugzilla.mozilla.org/show_bug.cgi?id=3D258136>. I very=
 
:>> :>> :>much welcome any suggestions on how to debug this
:>> :>
:>> :>Any ideas?
:>> 
:>> Those were not my comments but belonged to somebody else.
:>
:>Yes, me. I am looking for help debugging the problem and solving the b=
ug.
:>-- 
:>Gr=FC=DFe von
:>   Peter.



0
Hakan
3/11/2005 7:59:27 PM
Hakan wrote:

> "I" have the wrong attitude? You seem to be personally offended by what I,
> and others, consider design flaws in Firefox being pointed out.
 >
  I'm not offended by anyone pointing out design flaws. I'm offended by 
your expectation that someone will fix it for you, when you clearly have 
no intention to contribute anything.

 > Why are you
> so defensive about this?  Did you write this particular piece of code or is
> your reputation at stake?  If not, please relax.
> 
  I did not write that piece of code and in fact I never did any work on 
Mozilla/Firefox at all. For all I know, the design is as bad as you 
think. But I do have experience with other open source projects and your 
kind of users.

  My advice is: Fix it yourself or stop complaining. Anything else is a 
waste of time for everyone involved.


          Michal

0
Michal
3/11/2005 8:21:10 PM
In <utnqyrezrqqngnvappbz.id7e6o1.pminews@news.verizon.net>, on 03/11/2005
   at 07:59 PM, "Hakan" <bitbucket@127.0.0.1> said:

>By doing too much of the work in the main thread and not adhering to the
>1/10 second rule (or similar) -- on a "slow" computer where such things
>are more likely to become noticeable.  This is indeed an
>application-specific design issue.

Have you run Firefox under SMP versions of Linux or Windows on a setup
similar to yours to confirm your assertion that this is an
application-specific design issue?

While it is certainly true that there are cases where Firefox performance
under OS/2 is non-optimal, IMO your approach is not going to influence
people positively or convince them it is worthwhile to expend much effort
trying to help your resolve what appears to a problem specific to your
setup.

At times, you seem to claim to only want to report the issue rather than
fix it.  If so, this is an odd newsgroup to do this.  The focus of this
newsgroup is typically specific fixes to specific programming issues.

I recommend you take a look at an old thead on the mozilla os/2 newsgroup
with the subject:

 Mozilla page loading speed?

While the performance issue is yet to be fully resolved, a lot of folks
both programmers and non-programmers chose to invest their time to assist
with the analysis.

Regards,

Steven


-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
3/11/2005 8:45:57 PM
On Fri, 11 Mar 2005 20:45:57 GMT, Steven Levine wrote:

:>In <utnqyrezrqqngnvappbz.id7e6o1.pminews@news.verizon.net>, on 03/11/2005
:>   at 07:59 PM, "Hakan" <bitbucket@127.0.0.1> said:
:>
:>>By doing too much of the work in the main thread and not adhering to the
:>>1/10 second rule (or similar) -- on a "slow" computer where such things
:>>are more likely to become noticeable.  This is indeed an
:>>application-specific design issue.
:>
:>Have you run Firefox under SMP versions of Linux or Windows on a setup
:>similar to yours to confirm your assertion that this is an
:>application-specific design issue?

No, but I run /many/ other OS/2 applications on my SMP system.

:>While it is certainly true that there are cases where Firefox performance
:>under OS/2 is non-optimal, IMO your approach is not going to influence
:>people positively or convince them it is worthwhile to expend much effort
:>trying to help your resolve what appears to a problem specific to your
:>setup.

Why would it be specific to my setup when other people have agreed with me? 
I am actually holding little hope that the issues I brought up will be fixed
since they most likely are deep-seated design flaws and to a great extent are
masked when Firefox is run on a very fast computer.  As any programmer knows,
running applications on slower computers, faster computers, and SMP systems,
can bring different problems to the surface.  If the Firefox developers use
faster computers they are less likely to come across the issues I brought up
since the computer speed masks them -- this in no way invalidates them being
flaws, however.

:>At times, you seem to claim to only want to report the issue rather than
:>fix it.  If so, this is an odd newsgroup to do this.  The focus of this
:>newsgroup is typically specific fixes to specific programming issues.

I use many applications on my computer which have various shortcomings which
in no way invalidates any criticism I may have.  I also use products in my
daily life with various shortcomings and I feel perfectly free to vent any
reasonably argued opinion I may have on those.

:>I recommend you take a look at an old thead on the mozilla os/2 newsgroup
:>with the subject:
:>
:> Mozilla page loading speed?
:>
:>While the performance issue is yet to be fully resolved, a lot of folks
:>both programmers and non-programmers chose to invest their time to assist
:>with the analysis.

Unless I misrember, this thread was started by other people discussing
multi-threading and I brought Firefox/Mozilla into the picture as examples of
applications with design flaws.  I do not consider the Mozilla page loading
speed to be such a problem but I listed several examples where Firefox 1.0
ties up a system while performing various actions.  Some people -- and I am
not including you here -- reacted as if I had attacked them personally
without addressing the actual issues brought up.  Pointing out issues, by the
way, is also part of the analysis.

:>
:>Regards,
:>
:>Steven
:>
:>
:>-- 
:>--------------------------------------------------------------------------------------------
:>Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
:>Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
:>--------------------------------------------------------------------------------------------
:>





0
Hakan
3/11/2005 9:07:38 PM
>Hakan wrote:
>> "I" have the wrong attitude? You seem to be personally offended by what I,
>> and others, consider design flaws in Firefox being pointed out.

 >>  I'm not offended by anyone pointing out design flaws. I'm offended by
>>your expectation that someone will fix it for you, when you clearly have
>>no intention to contribute anything.

As I wrote in another message, I think it is unlikely that these design flaws
will be fixed.

>>Why are you
>> so defensive about this?  Did you write this particular piece of code or
is
>> your reputation at stake?  If not, please relax.

>  I did not write that piece of code and in fact I never did any work on
> Mozilla/Firefox at all. For all I know, the design is as bad as you
>think. But I do have experience with other open source projects and your
> kind of users.

Well, how about keeping the discussion on topic, on the issues I brought up
and whether my deductions are correct rather than resorting to another ad
hominem attack which you just did.

>  My advice is: Fix it yourself or stop complaining. Anything else is a
>waste of time for everyone involved.

>          Michal 


0
Hakan
3/11/2005 9:17:20 PM
how old are you???

"Hakan" <bitbucket@127.0.0.1> wrote in message
news:utnqyrezrqqngnvappbz.id7hs12.pminews@news.verizon.net...
> >Hakan wrote:
> >> "I" have the wrong attitude? You seem to be personally offended by what
I,
> >> and others, consider design flaws in Firefox being pointed out.
>
>  >>  I'm not offended by anyone pointing out design flaws. I'm offended by
> >>your expectation that someone will fix it for you, when you clearly have
> >>no intention to contribute anything.
>
> As I wrote in another message, I think it is unlikely that these design
flaws
> will be fixed.
>
> >>Why are you
> >> so defensive about this?  Did you write this particular piece of code
or
> is
> >> your reputation at stake?  If not, please relax.
>
> >  I did not write that piece of code and in fact I never did any work on
> > Mozilla/Firefox at all. For all I know, the design is as bad as you
> >think. But I do have experience with other open source projects and your
> > kind of users.
>
> Well, how about keeping the discussion on topic, on the issues I brought
up
> and whether my deductions are correct rather than resorting to another ad
> hominem attack which you just did.
>
> >  My advice is: Fix it yourself or stop complaining. Anything else is a
> >waste of time for everyone involved.
>
> >          Michal
>
>


0
eric
3/11/2005 9:48:03 PM
In <utnqyrezrqqngnvappbz.id7hbi1.pminews@news.verizon.net>, on 03/11/2005
   at 09:07 PM, "Hakan" <bitbucket@127.0.0.1> said:

>Why would it be specific to my setup when other people have agreed with
>me?

I guess we will have to agree to disagree.  I don't read the other
responses quite this way.

>As
>any programmer knows, running applications on slower computers, faster
>computers, and SMP systems, can bring different problems to the surface. 

I don't make assumptions like this.  The vast majority of programmers have
little need to understand the intricacies of SMP, multi-programming,
multi-tasking, hard real-time systems, memory constrained systems and such
and they don't.

>Unless I misrember, this thread was started by other people discussing
>multi-threading and I brought Firefox/Mozilla into the picture as
>examples of

You misremember.  Check out the thread on Goggle if you wish.  I posted a
specific test case and asked others if they could duplicate it and if it
was cross-platform.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
3/11/2005 10:47:22 PM
On Fri, 11 Mar 2005 22:47:22 GMT, Steven Levine wrote:

:>In <utnqyrezrqqngnvappbz.id7hbi1.pminews@news.verizon.net>, on 03/11/2005
:>   at 09:07 PM, "Hakan" <bitbucket@127.0.0.1> said:
:>
:>>Why would it be specific to my setup when other people have agreed with
:>>me?
:>
:>I guess we will have to agree to disagree.  I don't read the other
:>responses quite this way.

May I suggest you re-read Peter Moylan's response to my post?  I also have
offline comments from several other people who agree with me.

:>>As
:>>any programmer knows, running applications on slower computers, faster
:>>computers, and SMP systems, can bring different problems to the surface. 
:>
:>I don't make assumptions like this.  The vast majority of programmers have
:>little need to understand the intricacies of SMP, multi-programming,
:>multi-tasking, hard real-time systems, memory constrained systems and such
:>and they don't.

While I can understand that real-time system programming may not come into
the picture when developing Mozilla/Firefox, the other issues should.  This
is after all, an application which will be used on a wide variety of
computers, both fast and slow, and under different (modern) operating
systems.  It is not a niche application.

:>>Unless I misrember, this thread was started by other people discussing
:>>multi-threading and I brought Firefox/Mozilla into the picture as
:>>examples of

It was actually started by maverick909 under "WinStartApp woes" and later
morphed into "Firefox/Mozilla Threading".  Further, my original comment was
made as a follow-up to a posting by Aaron L.

:>You misremember.  Check out the thread on Goggle if you wish.  I posted a
:>specific test case and asked others if they could duplicate it and if it
:>was cross-platform.

May I suggest the same?  See my comment above.

If there is any interest in discussing potential design flaws in
Mozilla/Firefox, let's do that rather than resorting to personal attacks --
not you -- as several have done here, or make inane comments about age.

:>
:>Steven
:>
:>-- 
:>--------------------------------------------------------------------------------------------
:>Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
:>Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
:>--------------------------------------------------------------------------------------------
:>



0
Hakan
3/11/2005 11:13:35 PM
In <utnqyrezrqqngnvappbz.id7n3n1.pminews@news.verizon.net>, on 03/11/2005
   at 11:13 PM, "Hakan" <bitbucket@127.0.0.1> said:

>If there is any interest in discussing potential design flaws in
>Mozilla/Firefox,

Personnally, I have little or no interest in discussing potential design
flaws of any app.  My only real interest is doing what I can to resolve
what flaws might exist in the time I have available.

I tend to assume that those familiar with OS/2 programming understand the
weaknesses that exist and know how to avoid them.  For those new to OS/2
programming or to a particular aspect of OS/2 programming, it's a matter
of indentifying the problem at hand and pointing them in the correct
direction.  My POV is this is what happened in Maverick909's case.

Regards,

Steven


-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
3/12/2005 12:22:40 AM
 > The people who are programmers however are free to listen to the 
 > observations and then not act on them.
 
He wasn't addressing programmers.

 > We're probably very lucky that there's an OS/2 version at all,
 > and that is only thanks to IBM.
 
 > He's expecting that *someone else* will fix *his* problems
 
Mentioning a problem (as an example) isn't the same as expecting a
solution.

 > he is contributing nothing
 
I don't know that, and (http://www.mozilla.org/foundation/donate.html)
I understand paying 0.02 for it suddenly makes one able to 'expect' a
solution. Anyway, he already added his 0.02 in a posting here, which
IIRC was not aimed at (specific) programmers. But then again, I won't
insult people with 'contributing nothing' when it's possible that they
donated a lot of money. Even if he donated 0.00, I already appriciate
his 0.02 in this newsgroup, and I'm sure he knows that this isn't the
Mozilla Bug Report forum. 

 > (and no, reporting problems doesn't count as a contribution compared
 > to actually fixing something).
 
That's your comparization, not his (and it's probably irrelevant from
his POV). 

 > he thinks that this someone else will want to do it
 
That's just your claim, not his, isn't it?



---
0
spamgate
3/12/2005 9:31:56 AM
 > I also have offline comments from several other people who agree
 > with me.
 
FTR: here's an on-line one, without wanting to offend the other
authors. Just so people won't start to mention off-line friends,
which may or may not exist. My age is >12, it's not my homework
assignment to reply to Usenet 'wars' and my IQ>99 (so I'm not a
'real' programmer, obviously ;-)).

 > If there is any interest in discussing potential design flaws in
 > Mozilla/Firefox, let's do that rather than resorting to personal
 > attacks

TIA (even without the 'in Mozilla/Firefox'-part)!



---
0
spamgate
3/12/2005 9:47:42 AM
..    On  12.03.05
  wrote  spamgate@hotmai1.com (ML)
     on  /COMP/OS/OS2/PROGRAMMER/MISC
     in  McrMClQNAVBS090yn@hotmai1.com
  about  Re: Firefox/Mozilla threading


>> We're probably very lucky that there's an OS/2 version at all,
>> and that is only thanks to IBM.

>> He's expecting that *someone else* will fix *his* problems

s> Mentioning a problem (as an example) isn't the same as expecting a
s> solution.

  I haven't followed the whole thread, but the "Firefox/Mozilla" in  
the Subject attracted my attention.

  Anyway: I thinkt it is completely legitimate to point out problems  
with any software whatsoever and say "would please anybody fix it".

  OTOH, one does have a case for legal action _demanding_ a fix only  
when there is some contractual basis for such legal action. In the  
case of free software there isn't, which is probably the cause why so  
many businesses prefer to pay for software.

  With free software, any developer sure has the right to ignore such  
complaints or to shrug and say "use it as it is, or leave it".



Yours,
L�ko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Die gef�hrlichsten Unwahrheiten sind Wahrheiten m��ig entstellt. -G.C.Lichtenberg
0
l
3/12/2005 10:36:00 AM
On Sat, 12 Mar 2005 09:47:42 UTC, ML wrote:

>  > I also have offline comments from several other people who agree
>  > with me.
>  
> FTR: here's an on-line one, without wanting to offend the other
> authors.

Interesting. You agree with Hakan on what exactly?
-- 
Greetings,                         Please reply in newsgroup, I rarely
   Peter.                            read emails to pweilba@gwdg.de...
0
Peter
3/12/2005 2:43:26 PM
In <9SjfDPbuflB@jpberlin-l.willms.jpberlin.de>, on 03/12/2005
   at 10:36 AM, l.willms@jpberlin.de (Lueko Willms) said:

>  I haven't followed the whole thread, but the "Firefox/Mozilla" in   the
>Subject attracted my attention.

The entire thread is available for review on Google groups.  It's not all
that long, yet.

>  Anyway: I thinkt it is completely legitimate to point out problems  
>with any software whatsoever and say "would please anybody fix it".

Human interaction is a funny thing.  It is often more important how you
say something than what you say.  Of course your tagline implies you
already know this. :-)

Also, this is comp.os.os2.programmer.misc, not c.o.o.a.  Programmers tend
to read things literally and prefer to deal with specific issues so I
figure its a good idea to take this into account when posting here.

Regards,

Steven


-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.67 #10183
Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
3/12/2005 4:33:19 PM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Herbert Rosenau
<os2guy@pc-rosenau.de>], who wrote in article <wmzsGguTDN6N-pn2-qTUZpoGGdjPc@URANUS1.DV-ROSENAU.DE>:
> > > CLOCKSCALE=x in config.sys defines the time slice a thread can use:
> > > x = 4:  4ms
> > >     3:  8ms
> > >     2: 16ms
> > >     1: 32ms (same as if CLOCKSCALE not given.)
> > 
> > IFAIK, CLOCKSCALE affects only time-critical threads; the formula for
> > timeslice of these threads is 8ms/CLOCKSCALE (maybe clockscale should
> > be divisor of 8?).  The timeslice of other threads is always 32ms.
> 
> That is gone since Scott has implemented clockscale in the kernel. 
> clockscale was introduced to tune up anything on more modern CPUs as 
> 32ms is too long on that. It is related on any application.

I'm afraid you know little of what you wrote here. I *tested* before
posting.  (Kernel is of 2004; CLOCKSCALE=4.)  Did you?

Hope this helps,
Ilya

P.S.  To test, run

  perl5.00553 -wle "(select undef, undef, undef, 0.001 or 1) and ++$i and times > 1 and print $i and exit while 1"

This prints the approximate number of timeslices in a second (newer
Perls have special-code for short sleeps which behaves as if on
high-priority, so are not suitable to test the timeslice).
0
Ilya
3/12/2005 6:57:50 PM
Herbert Rosenau wrote:
> On Thu, 10 Mar 2005 21:24:20 UTC,  Ilya Zakharevich 
> <nospam-abuse@ilyaz.org> wrote:
> 
> 
>>[A complimentary Cc of this posting was NOT [per weedlist] sent to
>>Herbert Rosenau
>><os2guy@pc-rosenau.de>], who wrote in article <wmzsGguTDN6N-pn2-uC2FhgxdDVmv@URANUS1.DV-ROSENAU.DE>:
>>
>>>CLOCKSCALE=x in config.sys defines the time slice a thread can use:
>>>x = 4:  4ms
>>>    3:  8ms
>>>    2: 16ms
>>>    1: 32ms (same as if CLOCKSCALE not given.)
>>
>>IFAIK, CLOCKSCALE affects only time-critical threads; the formula for
>>timeslice of these threads is 8ms/CLOCKSCALE (maybe clockscale should
>>be divisor of 8?).  The timeslice of other threads is always 32ms.
> 
> 
> That is gone since Scott has implemented clockscale in the kernel. 
> clockscale was introduced to tune up anything on more modern CPUs as 
> 32ms is too long on that. It is related on any application.

And can you tell any difference between CLOCKSCALE=1 and 4? On my AMD 
Thunderbird 1.3GHz I can't.

Cheers,
Martin

>  
> 
>>>process management on most OSes is based on processes, so pthreads is 
>>>threads in user space - OS/2 threads are the base of OS/2 process 
>>>management.
>>
>>At least, this sentence is very confusing; most probably it is just
>>plain wrong.  pthreads on Unix use whatever implementation they want
>>(most advanced use combinations of user space threads and the kernel
>>threads).  pthreads on OS/2 may also use different implementations
>>(mine uses native threads).
> 
> 
> Unix knows nothing about threads.
> Linux prior kernel 2.6.x knows nothing about threads.
> Posix has phreads to give an application the possibility to use 
> multiple threads even as the kernel knows nothing about.
> I'm truly not informed yet how the state about kernel threads is on 
> the most current kernel in linux yet.
> 
> But OS/2 is designed on threads instead processes since its first 
> days. It is nice to know that your implementation of pthreads on OS/2 
> is based on kernel threads.
> 
> It looks like your code is well hidden somewhere.
> 
> As WEB master of ecomstation.de it would be of interest to get be 
> informed about anything you has written for OS/2 and where it can be 
> downloaded from. I would like to publish any information on that page 
> you can give me (plain text is enough, HTML (content only) would be 
> nice. Translation to german is no problem. You may use simply the 
> reply button on this artikle or send to info@ecomstation.de. Any side 
> information (copyright, author...) will be respected as ecomstation.de
> is designed to support ecomstation and its users in any possible way 
> instead to make out with such things.
> 
0
MMI
3/17/2005 11:30:24 AM
William L. Hartzell wrote:
> Sir:
> 
> MMI wrote:
> 
>> Herbert Rosenau wrote:
>>
>>> On Thu, 10 Mar 2005 21:24:20 UTC,  Ilya Zakharevich 
>>> <nospam-abuse@ilyaz.org> wrote:
>>>
>>>
>>>> [A complimentary Cc of this posting was NOT [per weedlist] sent to
>>>> Herbert Rosenau
>>>> <os2guy@pc-rosenau.de>], who wrote in article 
>>>> <wmzsGguTDN6N-pn2-uC2FhgxdDVmv@URANUS1.DV-ROSENAU.DE>:
>>>>
>>>>> CLOCKSCALE=x in config.sys defines the time slice a thread can use:
>>>>> x = 4:  4ms
>>>>>    3:  8ms
>>>>>    2: 16ms
>>>>>    1: 32ms (same as if CLOCKSCALE not given.)
>>>>
>>>>
>>>>
>>>> IFAIK, CLOCKSCALE affects only time-critical threads; the formula for
>>>> timeslice of these threads is 8ms/CLOCKSCALE (maybe clockscale should
>>>> be divisor of 8?).  The timeslice of other threads is always 32ms.
>>>
>>>
>>>
>>>
>>> That is gone since Scott has implemented clockscale in the kernel. 
>>> clockscale was introduced to tune up anything on more modern CPUs as 
>>> 32ms is too long on that. It is related on any application.
>>
>>
>>
>> And can you tell any difference between CLOCKSCALE=1 and 4? On my AMD 
>> Thunderbird 1.3GHz I can't.
>>
> <snip>
> If one was to think about this for a moment, one would realize that OS/2 
> was designed when 20 MHz CPU clocks were fast.  Now days 2 GHz CPU 
> clocks are common.  That is a thousand times faster, which is saying 
> that a thousand times as many instructions can be executed (not taking 
> into consideration the decomposition of 386 instructions into 
> microcode).  Most Active threads get replaced as the active thread upon 
> exit from the kernel.  The few that have the time slice and are doing 
> nothing, get booted off the CPU by the end of their time slice.  So the 
> question becomes one how many active and ready threads that will end 
> their time slice doing nothing?  Shorter time slice that clockscale 
> provides gives us benifit only for those threads that are doing nothing.

I'd object to the end of this paragraph a bit: The smaller timeslice, 
the more context switches per second, and more "smoother" multitasking 
feeling. Not only threads doing nothing benefit from the smaller 
timeslice, two threads doing something at the same priority level and 
delta get more context switches, so if they offer some visual clue (like 
progress bars or whatever painting at the screen) - user would feel them 
doing their work more smoothly. Am I wrong?

Cheers,
Martin

> Why don't you tell us how many threads get replaced by the time slice 
> code and how often?  Can you tell which of these threads were doing 
> something when replaced?
0
MMI
3/17/2005 3:11:26 PM
William L. Hartzell wrote:

> Does not painting the windows require entering the kernel?
> 
  Why should it? What would be entering the kernel?


          Michal

0
Michal
3/17/2005 6:50:18 PM
MMI wrote:

> I'd object to the end of this paragraph a bit: The smaller timeslice, 
> the more context switches per second, and more "smoother" multitasking 
> feeling. Not only threads doing nothing benefit from the smaller 
> timeslice,
 >
  How? Are you saying that if a thread finishes its work before the 
current timeslice expires, the next thread won't be scheduled until the 
*next* timeslice? That'd really surprise me.

 > two threads doing something at the same priority level and
> delta get more context switches, so if they offer some visual clue (like 
> progress bars or whatever painting at the screen) - user would feel them 
> doing their work more smoothly. Am I wrong?
> 
  That's assuming the user can distinguish between those events with 
millisecond accuracy. I don't think human perception is usually that good.

  All that can be said for certain is that if you keep shortening the 
timeslice, the overhead of task switching will be taking up 
progressively greater percentage of total CPU time. But I don't know how 
fast the switching would have to be at a given CPU frequency to become a 
noticeable drag on resources.


           Michal

0
Michal
3/17/2005 6:55:46 PM
Michal Necasek wrote:
> MMI wrote:
> 
>> I'd object to the end of this paragraph a bit: The smaller timeslice, 
>> the more context switches per second, and more "smoother" multitasking 
>> feeling. Not only threads doing nothing benefit from the smaller 
>> timeslice,
> 
>  >
>  How? Are you saying that if a thread finishes its work before the 
> current timeslice expires, the next thread won't be scheduled until the 
> *next* timeslice? That'd really surprise me.
> 
>  > two threads doing something at the same priority level and
> 
>> delta get more context switches, so if they offer some visual clue 
>> (like progress bars or whatever painting at the screen) - user would 
>> feel them doing their work more smoothly. Am I wrong?
>>
>  That's assuming the user can distinguish between those events with 
> millisecond accuracy. I don't think human perception is usually that good.

We can (or at least I can) tell the difference between 33ms and 17ms in 
that we can tell the difference between something updating at 60fps 
versus 30fps.  Not quite 1ms accuracy, but enough to see a difference 
from a 32ms time slice.

>  All that can be said for certain is that if you keep shortening the 
> timeslice, the overhead of task switching will be taking up 
> progressively greater percentage of total CPU time. But I don't know how 
> fast the switching would have to be at a given CPU frequency to become a 
> noticeable drag on resources.

That's the key.  32ms was devised to be relatively low overhead for a 
33MHz machine.  With machines that now run at almost 100x that speed, it 
was just time to change it.

0
Marty
3/17/2005 7:52:09 PM
On Fri, 18 Mar 2005 02:39:58 UTC in comp.os.os2.programmer.misc, 
"William L. Hartzell" <wlhartzell@comcast.net> wrote:

> OS/2 
> was designed when 20 MHz CPU clocks were fast.  Now days 2 GHz CPU 
> clocks are common.  That is a thousand times faster

20MHz vs 2000MHz is 100 not 1,000 times faster.

-- 
Trevor Hemsley, Brighton, UK.
Trevor-Hemsley at dsl dot pipex dot com
0
Trevor
3/17/2005 7:57:42 PM
[A complimentary Cc of this posting was sent to
Marty 
<net@comcast.martyamodeo>], who wrote in article <4239dfea$1@news.cadence.com>:
> >  How? Are you saying that if a thread finishes its work before the 
> > current timeslice expires, the next thread won't be scheduled until the 
> > *next* timeslice? That'd really surprise me.

Actually, I think this is what happens.  At least in the case when the
"next" thread was blocked on a timeout, but the timeout has already expired.

> >  That's assuming the user can distinguish between those events with 
> > millisecond accuracy. I don't think human perception is usually that good.
> 
> We can (or at least I can) tell the difference between 33ms and 17ms in 
> that we can tell the difference between something updating at 60fps 
> versus 30fps.  Not quite 1ms accuracy, but enough to see a difference 
> from a 32ms time slice.

You are confusing timeslices with high-precision waits.  To get 60fps,
you only need the latter.  And with CLOCK_SCALE, you get the best
combination: long timeslice (32ms), and down-to-1ms waits possible.

> >  All that can be said for certain is that if you keep shortening the 
> > timeslice, the overhead of task switching will be taking up 
> > progressively greater percentage of total CPU time. But I don't know how 
> > fast the switching would have to be at a given CPU frequency to become a 
> > noticeable drag on resources.

> That's the key.  32ms was devised to be relatively low overhead for a 
> 33MHz machine.  With machines that now run at almost 100x that speed, it 
> was just time to change it.

In my experience, 32ms is designed based on human physiology.  Unless
you have 10 CPU-bound threads, 32ms gives smooth enough
Human-Interaction process switch.  (At least until that scheduler bug
(?)  hits - one which sometimes gives 3sec delay when you try to
switch from a CPU-bound process.)

Hope this helps,
Ilya
0
Ilya
3/17/2005 10:10:43 PM
[A complimentary Cc of this posting was sent to
MMI 
<mmi@nautimail.com>], who wrote in article <c1.2b5.2vxpbl$0BQ@news.consultron.ca>:
> And can you tell any difference between CLOCKSCALE=1 and 4? On my AMD 
> Thunderbird 1.3GHz I can't.

How did you check, but clocking the time it boots up?  Or by looking
at CONFIG.SYS?  ;-)

Since CLOCKSCALE does not affect non-time-critical threads (unless
they use my trick for high-resolution waits), you need to know what
you do to see the difference.  Or use software which needs this high
resolution.

E.g,, I'm pretty sure that running

  Metronom 11 72

will get very different results (tested with CLOCKSCALE=4 here).  My
alias is (read from file)

  metronom perl -wle "die qq(Usage:\n\tMetronom BEATS_PER_MEASURE MEASURES_PER_MINUTE\n) unless @ARGV==2;$fr=440; $df=$fr*(2**(1/12)-1); $c=0; $f=shift; $t = OS2::Timer; $d=60/$f/shift; sub w($) {my $d=shift; my $r = OS2::Timer - $t; $t += $d*(my $sk = 1+int($r/$d)); $c+=$sk; OS2::ms_sleep(1000*($sk*$d-$r))} OS2::Beep($fr + $df*($c %% $f == 0),15), w($d) while 1"

Hope this helps,
Ilya
0
Ilya
3/17/2005 10:51:04 PM
Sir:

MMI wrote:
> Herbert Rosenau wrote:
> 
>> On Thu, 10 Mar 2005 21:24:20 UTC,  Ilya Zakharevich 
>> <nospam-abuse@ilyaz.org> wrote:
>>
>>
>>> [A complimentary Cc of this posting was NOT [per weedlist] sent to
>>> Herbert Rosenau
>>> <os2guy@pc-rosenau.de>], who wrote in article 
>>> <wmzsGguTDN6N-pn2-uC2FhgxdDVmv@URANUS1.DV-ROSENAU.DE>:
>>>
>>>> CLOCKSCALE=x in config.sys defines the time slice a thread can use:
>>>> x = 4:  4ms
>>>>    3:  8ms
>>>>    2: 16ms
>>>>    1: 32ms (same as if CLOCKSCALE not given.)
>>>
>>>
>>> IFAIK, CLOCKSCALE affects only time-critical threads; the formula for
>>> timeslice of these threads is 8ms/CLOCKSCALE (maybe clockscale should
>>> be divisor of 8?).  The timeslice of other threads is always 32ms.
>>
>>
>>
>> That is gone since Scott has implemented clockscale in the kernel. 
>> clockscale was introduced to tune up anything on more modern CPUs as 
>> 32ms is too long on that. It is related on any application.
> 
> 
> And can you tell any difference between CLOCKSCALE=1 and 4? On my AMD 
> Thunderbird 1.3GHz I can't.
> 
<snip>
If one was to think about this for a moment, one would realize that OS/2 
was designed when 20 MHz CPU clocks were fast.  Now days 2 GHz CPU 
clocks are common.  That is a thousand times faster, which is saying 
that a thousand times as many instructions can be executed (not taking 
into consideration the decomposition of 386 instructions into 
microcode).  Most Active threads get replaced as the active thread upon 
exit from the kernel.  The few that have the time slice and are doing 
nothing, get booted off the CPU by the end of their time slice.  So the 
question becomes one how many active and ready threads that will end 
their time slice doing nothing?  Shorter time slice that clockscale 
provides gives us benifit only for those threads that are doing nothing.

Why don't you tell us how many threads get replaced by the time slice 
code and how often?  Can you tell which of these threads were doing 
something when replaced?
-- 
Bill
Thanks a Million!
0
William
3/18/2005 2:39:58 AM
Sir:

MMI wrote:
> William L. Hartzell wrote:
> 
>> Sir:
>> 
>> MMI wrote:
>> 
>>> Herbert Rosenau wrote:
>>> 
>>>> On Thu, 10 Mar 2005 21:24:20 UTC,  Ilya Zakharevich 
>>>> <nospam-abuse@ilyaz.org> wrote:
>>>> 
>>>> 
>>>>> [A complimentary Cc of this posting was NOT [per weedlist]
>>>>> sent to Herbert Rosenau <os2guy@pc-rosenau.de>], who wrote in
>>>>> article 
>>>>> <wmzsGguTDN6N-pn2-uC2FhgxdDVmv@URANUS1.DV-ROSENAU.DE>:
>>>>> 
>>>>>> CLOCKSCALE=x in config.sys defines the time slice a thread
>>>>>> can use: x = 4:  4ms 3:  8ms 2: 16ms 1: 32ms (same as if
>>>>>> CLOCKSCALE not given.)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> IFAIK, CLOCKSCALE affects only time-critical threads; the
>>>>> formula for timeslice of these threads is 8ms/CLOCKSCALE
>>>>> (maybe clockscale should be divisor of 8?).  The timeslice of
>>>>> other threads is always 32ms.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> That is gone since Scott has implemented clockscale in the
>>>> kernel. clockscale was introduced to tune up anything on more
>>>> modern CPUs as 32ms is too long on that. It is related on any
>>>> application.
>>> 
>>> 
>>> 
>>> 
>>> And can you tell any difference between CLOCKSCALE=1 and 4? On my
>>> AMD Thunderbird 1.3GHz I can't.
>>> 
>> <snip> If one was to think about this for a moment, one would
>> realize that OS/2 was designed when 20 MHz CPU clocks were fast.
>> Now days 2 GHz CPU clocks are common.  That is a thousand times
>> faster, which is saying that a thousand times as many instructions
>> can be executed (not taking into consideration the decomposition of
>> 386 instructions into microcode).  Most Active threads get replaced
>> as the active thread upon exit from the kernel.  The few that have
>> the time slice and are doing nothing, get booted off the CPU by the
>> end of their time slice. So the question becomes one how many
>> active and ready threads that will end their time slice doing
>> nothing?  Shorter time slice that clockscale provides gives us
>> benifit only for those threads that are doing nothing.
> 
> 
> I'd object to the end of this paragraph a bit: The smaller timeslice,
>  the more context switches per second, and more "smoother"
> multitasking feeling. Not only threads doing nothing benefit from the
> smaller timeslice, two threads doing something at the same priority
> level and delta get more context switches, so if they offer some
> visual clue (like progress bars or whatever painting at the screen) -
> user would feel them doing their work more smoothly. Am I wrong?
> 
But how many times would a thread that updated any windows not be
replace upon exit from the kernel?  Does not painting the windows
require entering the kernel?
> 
>> Why don't you tell us how many threads get replaced by the time
>> slice code and how often?  Can you tell which of these threads were
>> doing something when replaced?

-- 
Bill
Thanks a Million!
0
William
3/18/2005 3:41:44 AM
On Sat, 12 Mar 2005 04:59:29 +1300, Aaron Lawrence
<aaronlNOT@HEREconsultant.com> wrote:

>> Seems like I have got a lot to learn, where should i start picking up
>> PM multithreading concepts. 
> 
> There aren't many :)
> 
> 1) You can't multithread PM code except

Huh? Most of the WPS threads use PM code.

> 2) you can multithread drawing
> 
> so you can't call any PM controls etc from another thread.

Yes you can. It may involve a cross-thread WinSendMsg though. Read the
Remarks section of WinSendMsg() in the PM Ref.

> Generally this means posting messages back to your main window to tell 
> it to show results/progress.

With all the headaches that go with it.
0
Paul
3/19/2005 11:54:20 AM
Suddenly, Paul Ratcliffe sprang forth and uttered these pithy words:
> > so you can't call any PM controls etc from another thread.
> 
> Yes you can. It may involve a cross-thread WinSendMsg though. Read the
> Remarks section of WinSendMsg() in the PM Ref.

Interesting.  I did not know that. 

From the pmref:

"Any thread in the application can post a message to a message queue, 
even if the thread has no message queue of its own.  However, only a 
thread that has a message queue can send a message.  Sending a message 
between threads is relatively uncommon.  For one reason, sending a 
message is costly in terms of system performance.  If an application 
posts a message between threads, it is likely to be a semaphore message, 
which permits window procedures to manage a shared resource jointly. "

So... they are saying that is a pretty inefficient way to work. Implies 
that you wouldn't, for instance, want to fill a listbox this way. Or are 
they just being conservative?

What about API functions? What of those can you call (if any) from 
another thread?

> > Generally this means posting messages back to your main window to tell 
> > it to show results/progress.
> 
> With all the headaches that go with it.

Are you saying this is wrong, or just that it is a tricky job to do 
right?
 

-- 
aaronl at consultant dot com 
For every expert, there is an equal and 
opposite expert. - Arthur C. Clarke
0
Aaron
3/19/2005 1:40:20 PM
Aaron Lawrence wrote:
> Suddenly, Paul Ratcliffe sprang forth and uttered these pithy words:
> 
>>>so you can't call any PM controls etc from another thread.
>>
>>Yes you can. It may involve a cross-thread WinSendMsg though. Read the
>>Remarks section of WinSendMsg() in the PM Ref.
> 
> 
> Interesting.  I did not know that. 
> 
> From the pmref:
> 
> "Any thread in the application can post a message to a message queue, 
> even if the thread has no message queue of its own.  However, only a 
> thread that has a message queue can send a message.  Sending a message 
> between threads is relatively uncommon.  For one reason, sending a 
> message is costly in terms of system performance.  If an application 
> posts a message between threads, it is likely to be a semaphore message, 
> which permits window procedures to manage a shared resource jointly. "
> 
> So... they are saying that is a pretty inefficient way to work. Implies 
> that you wouldn't, for instance, want to fill a listbox this way. Or are 
> they just being conservative?

Interthread communication by message queues may not be efficient, 
however it doesn't say anything about being unable to use PM calls in 
more than one thread. You can create several windows and have each 
window managed by one thread, with each thread having its own message queue.

Cheers,
Martin

> 
> What about API functions? What of those can you call (if any) from 
> another thread?
> 
> 
>>>Generally this means posting messages back to your main window to tell 
>>>it to show results/progress.
>>
>>With all the headaches that go with it.
> 
> 
> Are you saying this is wrong, or just that it is a tricky job to do 
> right?
>  
> 
0
MMI
3/19/2005 7:40:54 PM
Aaron Lawrence wrote:
> Suddenly, Paul Ratcliffe sprang forth and uttered these pithy words:
> 
>>>so you can't call any PM controls etc from another thread.
>>
>>Yes you can. It may involve a cross-thread WinSendMsg though. Read the
>>Remarks section of WinSendMsg() in the PM Ref.
> 
> Interesting.  I did not know that. 
> 
> From the pmref:
> 
> "Any thread in the application can post a message to a message queue, 
> even if the thread has no message queue of its own.  However, only a 
> thread that has a message queue can send a message.  Sending a message 
> between threads is relatively uncommon.  For one reason, sending a 
> message is costly in terms of system performance.  If an application 
> posts a message between threads, it is likely to be a semaphore message, 
> which permits window procedures to manage a shared resource jointly. "
> 
> So... they are saying that is a pretty inefficient way to work. Implies 
> that you wouldn't, for instance, want to fill a listbox this way. Or are 
> they just being conservative?

As we've seen in the Windows world, users will tolerate a great deal of 
inefficiency, and improving hardware makes it less unacceptable over 
time.  To fill I list box, I would recommend sending the data in one big 
chunk to a special message rather than individual cross-thread/message 
queue messages.

> What about API functions? What of those can you call (if any) from 
> another thread?

As long as you have initialized the message queue in that thread, you 
can call any API calls from it.

>>>Generally this means posting messages back to your main window to tell 
>>>it to show results/progress.
>>
>>With all the headaches that go with it.
> 
> Are you saying this is wrong, or just that it is a tricky job to do 
> right?

As you're aware, I'm sure, it's just tricky managing memory 
allocation/deallocation and mutual exclusion.  It is a good way of doing 
things IMO, but a bit complex.  It's much better than doing all of the 
work and the GUI updates in a single thread from a user experience 
perspective.

-- 
[Reverse the parts of the e-mail address to reply.]
0
Marty
3/20/2005 12:04:25 AM
On Sat, 19 Mar 2005 13:40:20 UTC, Aaron Lawrence <aaronlNOT@HEREconsultant.com> wrote:
> Suddenly, Paul Ratcliffe sprang forth and uttered these pithy words:

> > > so you can't call any PM controls etc from another thread.
> > 
> > Yes you can. It may involve a cross-thread WinSendMsg though. Read the
> > Remarks section of WinSendMsg() in the PM Ref.
> 
> From the pmref:
> 
> [snip] Sending a message between threads is relatively uncommon. For one
> reason, sending a  > message is costly in terms of system performance.
> 
> So... they are saying that is a pretty inefficient way to work. Implies 
> that you wouldn't, for instance, want to fill a listbox this way. Or are 
> they just being conservative?

There's another far more significant reason for not sending msgs between
threads:  the sender has no way of knowing whether the receiving thread
is capable of processing the msg.

When you send a msg to another thread, your thread is suspended and the
msg is held until it can be dispatched.  This can only occur when the
target thread has returned control to PM by calling WinGetMsg().  If the
target is busy handling another msg, yours has to wait.  If it fails to
service its queue because it's in an endless loop or it's suspended due
to some resource deadlock, the sending thread will remain suspended -
maybe indefinitely.  AFAIK, there's no way the source can know if the
target is in such a state.

If the sender doesn't have any windows, then some part of the app's
functionality will stop working.  However, if it does have a visible
window, then the first time the user moves the mouse over that window,
the SIQ will lock up.

You can use d&d to test this because it works by sending interprocess
msgs.  Create a test dialog with a single default button;  when pressed,
have the app call DosSleep() for a minute or two.  To test, put the
window in a corner of the screen, give it the focus, then press Enter
to "press" the button (do not use the mouse).

Now click on a Desktop icon, then start dragging it.  Until the mouse
hits your window, everything will work great and you can do whatever
you want.  However, as soon as you drag onto the sleeping window, the
icon will get stuck halfway across its frame and your GUI will be
useless until the window wakes up.

> What about API functions? What of those can you call (if any) from 
> another thread?

There are a few that must be invoked on the same thread that created
the window.  WinDestroyWindow() is the one that comes to mind;  I
suppose there are a few others.
 
> > > Generally this means posting messages back to your main window
> > > to tell  it to show results/progress.
> > 
> > With all the headaches that go with it.
> 
> Are you saying this is wrong, or just that it is a tricky job to do 
> right?

Presumably, it's just tricky in some situations - but overall, safer.


-- 
== == almost usable email address:  rich AT e-vertise.com == ==
___________________________________________________________________
                |
                |       New - Remote Workplace Server v0.60
Rich Walsh      |      interact with the WPS from any program
Ft Myers, FL    |       http://e-vertise.com/rws/rws060.zip
___________________________________________________________________
0
Rich
3/20/2005 6:52:46 AM
Rich Walsh wrote:
> On Sat, 19 Mar 2005 13:40:20 UTC, Aaron Lawrence <aaronlNOT@HEREconsultant.com> wrote:
> 
>>Suddenly, Paul Ratcliffe sprang forth and uttered these pithy words:
> 
> 
>>>>so you can't call any PM controls etc from another thread.
>>>
>>>Yes you can. It may involve a cross-thread WinSendMsg though. Read the
>>>Remarks section of WinSendMsg() in the PM Ref.
>>
>>From the pmref:
>>
>>[snip] Sending a message between threads is relatively uncommon. For one
>>reason, sending a  > message is costly in terms of system performance.
>>
>>So... they are saying that is a pretty inefficient way to work. Implies 
>>that you wouldn't, for instance, want to fill a listbox this way. Or are 
>>they just being conservative?
> 
> 
> There's another far more significant reason for not sending msgs between
> threads:  the sender has no way of knowing whether the receiving thread
> is capable of processing the msg.
> 
> When you send a msg to another thread, your thread is suspended and the

How so? You may WinPostMsg() if you don't care much about message 
processing return value etc.

Cheers,
Martin

> msg is held until it can be dispatched.  This can only occur when the
> target thread has returned control to PM by calling WinGetMsg().  If the
> target is busy handling another msg, yours has to wait.  If it fails to
> service its queue because it's in an endless loop or it's suspended due
> to some resource deadlock, the sending thread will remain suspended -
> maybe indefinitely.  AFAIK, there's no way the source can know if the
> target is in such a state.
> 
> If the sender doesn't have any windows, then some part of the app's
> functionality will stop working.  However, if it does have a visible
> window, then the first time the user moves the mouse over that window,
> the SIQ will lock up.
> 
> You can use d&d to test this because it works by sending interprocess
> msgs.  Create a test dialog with a single default button;  when pressed,
> have the app call DosSleep() for a minute or two.  To test, put the
> window in a corner of the screen, give it the focus, then press Enter
> to "press" the button (do not use the mouse).
> 
> Now click on a Desktop icon, then start dragging it.  Until the mouse
> hits your window, everything will work great and you can do whatever
> you want.  However, as soon as you drag onto the sleeping window, the
> icon will get stuck halfway across its frame and your GUI will be
> useless until the window wakes up.
> 
> 
>>What about API functions? What of those can you call (if any) from 
>>another thread?
> 
> 
> There are a few that must be invoked on the same thread that created
> the window.  WinDestroyWindow() is the one that comes to mind;  I
> suppose there are a few others.
>  
> 
>>>>Generally this means posting messages back to your main window
>>>>to tell  it to show results/progress.
>>>
>>>With all the headaches that go with it.
>>
>>Are you saying this is wrong, or just that it is a tricky job to do 
>>right?
> 
> 
> Presumably, it's just tricky in some situations - but overall, safer.
> 
> 
0
MMI
3/20/2005 11:13:01 AM
In article <9O2dnTDvusuXI6HfRVn-sQ@comcast.com>,
Marty <net@comcast.martyamodeo> wrote:

 >As we've seen in the Windows world, users will tolerate a great deal of
 >inefficiency, and improving hardware makes it less unacceptable over
 >time.  To fill I list box, I would recommend sending the data in one big
 >chunk to a special message rather than individual cross-thread/message
 >queue messages.

in past I made a program with an object window thread to scan the disk
for bitmap files and get their bitmap handle, for each file a message
was sent to the main PM thread to add an item to a list box
the list box was user drawn to display part of the bitmap
and even with the user draw overhead everything ran smoothly even on
an old Pentium 100 - 16 MB machine...

--
bye
Alessandro Cantatore
email reply to: acantatore_at_tin_dot_it
0
tin
3/20/2005 1:15:14 PM
On Sat, 19 Mar 2005 13:40:20 UTC, Aaron Lawrence 
<aaronlNOT@HEREconsultant.com> wrote:

> Suddenly, Paul Ratcliffe sprang forth and uttered these pithy words:
> > > so you can't call any PM controls etc from another thread.
> > 
> > Yes you can. It may involve a cross-thread WinSendMsg though. Read the
> > Remarks section of WinSendMsg() in the PM Ref.
> 
> Interesting.  I did not know that. 
> 
> From the pmref:
> 
> "Any thread in the application can post a message to a message queue, 
> even if the thread has no message queue of its own.  However, only a 
> thread that has a message queue can send a message.  Sending a message 
> between threads is relatively uncommon.  For one reason, sending a 
> message is costly in terms of system performance.  If an application 
> posts a message between threads, it is likely to be a semaphore message, 
> which permits window procedures to manage a shared resource jointly. "
> 
> So... they are saying that is a pretty inefficient way to work. Implies 
> that you wouldn't, for instance, want to fill a listbox this way. Or are 
> they just being conservative?

No. It tells only some facts. You would know that you should never do 
an lenghly action in a message. So when you have the job to fill a 
listbox with many data you have to do a very, very long job to do.

The best way is
1. inform another thread that it has to collect the content
   of the window. Posting a message to the opbject window
   of the other thread is not a bad idea
   The other thread would own a message queue to be able
   - to use PM-APIs
   - send messages
   - holding an object window and a related message queue
     to be able to receive messages (mostenly WM_USER)
2. use that thread to collect the data from its source
   e.g. a directory tree, a collection of files......
   That thread would do
2.1. WinEnableWindow(hwndLB, FALSE)
   to block the window from updating itself
   that means it does NOT draw its content when it gets changed
2.2. looping through its data collection, building the
     listbox entries one after one and sending them
     to the window maintaining the listbox
2.3. WinEnableWindow(hwndLB, TRUE)
     to enable window update again. This will 
     draw the full filled listbox.
  Disabling the window is saving 30.000% of time and tunes
  up the whole work.
  Having this job outlined gives the window itsels and
  the system too the possibility to interact with any
  message from the system queue.

Sending a message is done in this steps:
1. fill the message in senders message queue
2. hold sender until message result is known
   That means that the sender will loose the rest of its
   timeslice.
3. the receiver will read the senders message queue and
   enter the message procedure
   That means: its stack and current registers gets saved
   and its instruction register is set to start of the
   message procedure with the message and its parameters
   as current values. That means that independant what
   the receiver is doing currently the sended message
   gets working on. return from the message is done by
   reloading the stack, processor registers to the state
   they were at the time the message received. The return
   value of the message gets communicated to the sender
   and it will return it.
   So independant of if the sender and receiver are the
   same or different thread/application the message
   gets done. The effect is that a WindowProc() gets
   called multiple recursive.

   A posted message gets simply stored into the message 
   queue of the receiver and will be dispatched when it
   calls WinDispatchMsg().

Posting lots of messages can overflow the message queue of the sender!
Because the receiver may not be able to receive a message yet as it
- gets no CPU until the timeslice of the sender runs out
- gets CPU but is busy on another message.

So when you tries to fill a listbox/container or other control with 
lots of messages you should send them.

WinSendMsg() -> syncronous work is done
WinPostMsg() -> work is done asyncronous, receivers message queue gets
flooded.

> 
> What about API functions? What of those can you call (if any) from 
> another thread?

You needs a message queue for most of them. Some APIs are simply 
macros, disguised only as API, some are real APIs, some results in 
sending or posting one or multiple messages under hood.
 
> > > Generally this means posting messages back to your main window to tell 
> > > it to show results/progress.
> > 
> > With all the headaches that go with it.
> 
> Are you saying this is wrong, or just that it is a tricky job to do 
> right?

It is a bit tricky. In a loop that produces lots of messages: send 
them.
Otherwise when you can ignore the result of a message post it.

Blocking drawing of the receiver window wins significantly more time 
as you ever can loose by sending multiple messages. Even on a 80386 
you can send some 10,000 messages to a window in less than 1 second 
while the receiver gots forbidden to update its content on screen. For
the same number of messages you needs there about 1 hour to send the 
same (number of) messages when the receiver has to update its window 
for each message. Even on a P8 the time difference is noticeable.

Rermark:

An object window does not receive system messages. So it is a good 
anchor for a message procedure that does never own drawing but works 
on long time messages. It works well as isolation between system queue
and real work.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/21/2005 9:26:25 AM
On Sun, 20 Mar 2005 06:52:46 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> There's another far more significant reason for not sending msgs between
> threads:  the sender has no way of knowing whether the receiving thread
> is capable of processing the msg.

Not true.
 
> When you send a msg to another thread, your thread is suspended and the
> msg is held until it can be dispatched.

That is absolutely false. There is no difference in sending a message 
to the own window and to other windows in the same or different 
thread/application. 

  This can only occur when the
> target thread has returned control to PM by calling WinGetMsg().  If the
> target is busy handling another msg, yours has to wait.  If it fails to
> service its queue because it's in an endless loop or it's suspended due
> to some resource deadlock, the sending thread will remain suspended -
> maybe indefinitely.  AFAIK, there's no way the source can know if the
> target is in such a state.

That is absolutely false! Sending a message is syncronousely. That 
means the receiver gets intermittent until the message returns.

> 
> If the sender doesn't have any windows, then some part of the app's
> functionality will stop working.  However, if it does have a visible
> window, then the first time the user moves the mouse over that window,
> the SIQ will lock up.

False too. There is no need for a window - only a message queue is 
required for sending messages. Moving the mouse has nothing to do with
breaking the SIQ (the System (not single) Message Queue).
 
> You can use d&d to test this because it works by sending interprocess
> msgs.  Create a test dialog with a single default button;  when pressed,
> have the app call DosSleep() for a minute or two.  To test, put the
> window in a corner of the screen, give it the focus, then press Enter
> to "press" the button (do not use the mouse).

Has nothing to do with blocking. Has only to do with misbehaving and 
unability to think of the developer!

Since the very first days of PM there are a golden rule:
No message should run longer than 1/10s. When the work needs more time
it is to isolate from the message.

Do the work right:
Create a thread that contains the window above: and even as the window
procedure is on a DosSleep(60*60*60) the system will interact well - 
even as the specific window will do absolutely nothing.
 
> Now click on a Desktop icon, then start dragging it.  Until the mouse
> hits your window, everything will work great and you can do whatever
> you want.  However, as soon as you drag onto the sleeping window, the
> icon will get stuck halfway across its frame and your GUI will be
> useless until the window wakes up.

Drag&Drop is an atomic operation, true. But when you as developer is 
too dumb to understund how PM works it is YOUR bug - not the one of 
the system.
 
> > What about API functions? What of those can you call (if any) from 
> > another thread?
> 
> There are a few that must be invoked on the same thread that created
> the window.  WinDestroyWindow() is the one that comes to mind;  I
> suppose there are a few others.

Wrong, absolutely wrong. Hacking around with resources you does nopt 
own has always stronge effects. You does nothing than wildcatting.
  
> > > > Generally this means posting messages back to your main window
> > > > to tell  it to show results/progress.
> > > 
> > > With all the headaches that go with it.
> > 
> > Are you saying this is wrong, or just that it is a tricky job to do 
> > right?
> 
> Presumably, it's just tricky in some situations - but overall, safer.

No, not true.

Read the artikle I've written to Aaron. Wildcatting does not help.

You should inform you about the differences between posting and 
sending messages.

How would WinSendMsg work when the sender and the receiver the same 
window or even different windows on the same thread? When you were 
right the sender would never receive the result of the message because
he is blocked on send but needs to receive the result of the message 
to continue but can't continue because the message would only worked 
on when he returns from its current message. 

Prove it by yourself:
Create a thread.
Create a standardwindow with title="sleeptest" on it having a message 
procedure that will receive
WM_USER: job: 
1. change own titlebar to "I sleep now"
2. for (i = 0; i < 1000000) DosSleep(60*60*60);
3. After the loop change your titlebar to "I sleeped well"
and handle all system messages right. 

In mainthread: fire up the thread, create another independant window 
with 2 buttons:
1. button: on press POST a WM_USER to the window of the other thread
   Thereafter change the titlebar of that window to "I does NOT sleep"
2. button: on press SEND the same WM_USER to the window.
   Thereafter change the titlebar of that window to "I had sleeped"

You'll see the difference. Describe it.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/21/2005 10:02:04 AM
On Mon, 21 Mar 2005 10:02:04 UTC, "Herbert Rosenau" wrote:
> On Sun, 20 Mar 2005 06:52:46 UTC, "Rich Walsh" wrote:
> 
> > There's another far more significant reason [...]
> 
> Not true.
<snip>
> That is absolutely false. 
<snip>
> That is absolutely false!
<snip>
> False too.
<snip>
> Has nothing to do with blocking.
<snip>
> Do the work right:
<snip>
> Wrong, absolutely wrong.
<snip>
> No, not true.

[rolling eyes heavenward] No comment...


-- 
== == almost usable email address:  rich AT e-vertise.com == ==
___________________________________________________________________
                |
                |       New - Remote Workplace Server v0.60
Rich Walsh      |      interact with the WPS from any program
Ft Myers, FL    |       http://e-vertise.com/rws/rws060.zip
___________________________________________________________________
0
Rich
3/23/2005 1:27:26 AM
On Mon, 21 Mar 2005 09:26:25 UTC, "Herbert Rosenau" wrote:
> 
> Sending a message is done in this steps:
> 1. fill the message in senders message queue
> 2. hold sender until message result is known
>    That means that the sender will loose the rest of its
>    timeslice.
> 3. the receiver will read the senders message queue and
>    enter the message procedure
>    That means: its stack and current registers gets saved
>    and its instruction register is set to start of the
>    message procedure with the message and its parameters
>    as current values. That means that independant what
>    the receiver is doing currently the sended message
>    gets working on. return from the message is done by
>    reloading the stack, processor registers to the state
>    they were at the time the message received. The return
>    value of the message gets communicated to the sender
>    and it will return it.
>    So independant of if the sender and receiver are the
>    same or different thread/application the message
>    gets done. The effect is that a WindowProc() gets
>    called multiple recursive.

Well, isn't that interesting!  According to #3, you're saying
that sent messages act like IRQs and can interrupt a thread's
current processing.  Gee!  Even more amazing, you're saying
that threads are themselves multi-threaded, i.e. they can have
multiple contexts at the same time.  Wow!  If this situation
arose on an SMP machine, would you end up with the very same
thread running on 2 separate processors?

Golly!  I never realized OS/2 was such an advanced o/s...


-- 
== == almost usable email address:  rich AT e-vertise.com == ==
___________________________________________________________________
                |
                |       New - Remote Workplace Server v0.60
Rich Walsh      |      interact with the WPS from any program
Ft Myers, FL    |       http://e-vertise.com/rws/rws060.zip
___________________________________________________________________
0
Rich
3/23/2005 3:31:05 AM
On Wed, 23 Mar 2005 03:31:05 UTC, "Rich Walsh" 
<spamyourself@127.0.0.1> wrote:

> On Mon, 21 Mar 2005 09:26:25 UTC, "Herbert Rosenau" wrote:
> > 
> > Sending a message is done in this steps:
> > 1. fill the message in senders message queue
> > 2. hold sender until message result is known
> >    That means that the sender will loose the rest of its
> >    timeslice.
> > 3. the receiver will read the senders message queue and
> >    enter the message procedure
> >    That means: its stack and current registers gets saved
> >    and its instruction register is set to start of the
> >    message procedure with the message and its parameters
> >    as current values. That means that independant what
> >    the receiver is doing currently the sended message
> >    gets working on. return from the message is done by
> >    reloading the stack, processor registers to the state
> >    they were at the time the message received. The return
> >    value of the message gets communicated to the sender
> >    and it will return it.
> >    So independant of if the sender and receiver are the
> >    same or different thread/application the message
> >    gets done. The effect is that a WindowProc() gets
> >    called multiple recursive.
> 
> Well, isn't that interesting!  According to #3, you're saying
> that sent messages act like IRQs and can interrupt a thread's
> current processing.  Gee!  Even more amazing, you're saying
> that threads are themselves multi-threaded, i.e. they can have
> multiple contexts at the same time.  Wow!  If this situation
> arose on an SMP machine, would you end up with the very same
> thread running on 2 separate processors?
> 
> Golly!  I never realized OS/2 was such an advanced o/s...

There is some misunderstunding:

No, a thread as such gets not multithreaded.
The thread calling WinSendMsg() is the current owner of the CPU, so
- on single processor system: no other thread can own the CPU
- on multiple processor systems: the receiver thread can simply
  holded by an official well documented API.

There is nothing on the hardware that forbids to read and store 
somewhere registers, including stack pointer, instruction 
pointer......

So saving the whole register set of an thread is easy done. Loading it
with other values too. It is one of the very well hidden features of 
PM how it does this:

1. freeze the thread
2. save its register set
3. set up it to be ready to work on the sended message
   This is a well defined point somwhere inside PM.
4. unfreeze the thread
   Now the thread continues after it gets CPU on another
   instruction as it was ready for as it got interrupted
   for the new message.
5. let the message do its works.
6. freeze the thread
7. store the result of the message into the approbiate place
8. reload the register set stored under 1.
9. unfreeze the thread
   Now the thread continues after it gets CPU on another
   instruction as it was ready for as it got interrupted
   This instruction will be simply the one it was the next
   at the time 1. occured.
10. load the message result into the register the sender awaits it.
11. return to sender.

In effect it is the same as if you calls a subroutine - but the 
control over this is outside your influence. Tricky, yes - but works.

It is the PM that controls anything a thread can do after 
WinInitialise() is called. A window procedure is nothing than a 
callback into PM. PM controls where work on a message starts. It 
controls too where it ends. 
 
You can well debug this behavior using a debugger. I don't know which 
CPU the programm manager assigns to a thread that is waiting for 
getting CPU. It may or may not assign the same CPU to it.

-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
0
Herbert
3/23/2005 7:54:34 PM
On Wed, 23 Mar 2005 19:54:34 UTC, "Herbert Rosenau" <os2guy@pc-rosenau.de> 
wrote:

> So saving the whole register set of an thread is easy done. Loading it
> with other values too. It is one of the very well hidden features of 
> PM how it does this:
>  
> 1. freeze the thread
> 2. save its register set
>   ...SNIP

this sounds like the INTERRUPT MECHANISM (not PM) & the code responsible for 
the "hidden feature" is the appropriate interrupt handler... 


0
eric
3/24/2005 6:24:46 PM
Reply:

Similar Artilces:

Programmers, Programmers, Programmers, ...
As Steve Balmer correctly stated, while making his monkey dance, it is applications and hence programmers that make a platform. The fact though is that if you want to do professional programming, then Linux is the platform for you. I know that this statement will get the heckels up on a lot of trolls in C.O.L.A, but I have a recent experience that proves this. I am currently working for a Windows only house producing a system that receives and transmits around 1000 telegrams per second in each direction on a UDP socket, translates them into a different format and creates a log entry for each ...

OS Programmers
Are there any C/C++/Assembler programmers here ? Because i'm looking for programmers who are interested in writing a new OS. I don't have a name for it yet. So if there are any suggestions for a name give it a shot Wolfbyte wrote: > Are there any C/C++/Assembler programmers here ? > Because i'm looking for programmers who are interested > in writing a new OS. I don't have a name for it yet. > So if there are any suggestions for a name give it a shot I'm a C and assembler programmer. Let me give you some advice. Unless you have a pretty good idea about how ...

RE: Obsucure Inquier article about Intel mentions VMS (and not any other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other
> -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 > Sent: October 11, 2004 11:45 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Obsucure Inquier article about Intel mentions=20 > VMS (and not any other OS') other OS') other OS') other OS')=20 > other OS') other OS') other OS') other OS') other OS') other=20 > OS') other OS') other OS') other OS') other OS') other OS') other=20 >=20 > "Main, Kerry" wrote: > > Course, there are many ways to offer differen...

RE: Obsucure Inquier article about Intel mentions VMS (and not any other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS') other OS')
> -----Original Message----- > From: Soterro [mailto:soterroatyahoocom@address.hp.com]=20 > Sent: October 11, 2004 9:43 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Obsucure Inquier article about Intel mentions=20 > VMS (and not any other OS') other OS') other OS') other OS')=20 > other OS') other OS') other OS') other OS') other OS') >=20 > Main, Kerry wrote: > >>From: John Smith [mailto:a@nonymous.com]=20 > >>You aren't directly to blame for this and I know you'd like=20 > >>to keep your > &...

some OS X woes
Observed on both 10.2.6 and 10.2.7: When making a new window with Cmd-N, why doesn't the window use the All Windows settings? I have to manually Cmd-J and set it the settings for every stupid window I open. When I have a window open and I click from This Window Only to All Windows the behavior is effectively random. Sometimes the window automatically switches to the All Windows settings. Sometimes not and I have to change one of the settings to get the window to catch the settings (and change it back because I didn't really want to change it in the first place). Why does it appea...

WinStartApp woes ctd.
Hmmm, Looks like im doing something really stupid. Nothing seems to work out. Im using IBM C/C++ compilers 3.6 A very detailed description of my problem. 1. There is a front end PM application window which makes some API calls into a DLL. 2. For each API call it spawns a new thread and waits till the thread dies. (Im using DosCreateThread and DosWait). 3.Now the DLL called relays it to another DLL, which essentially calls WinStartApp to launch netscape. 4. The function which calls WinStartApp does the following - WinInitialize, WinCreateMsgQueue,WinCreateWindow, WinStartApp and ...

OS X woes
I finally decided to switch to OS X. I was waiting until I absolutely had to. Quicken Bill Pay requires Quicken 2006 which only works in OS X. I can't live without Bill Pay. So that was the last straw. But I am having no end of problems with OS X Tiger. Backup. I just discovered that Deja Vu is just not working. It takes hours to run a backup and it is stopping with errors part way through. Is there a better backup program that will create bootable backups? I must have bootable backups. Somehow the system thinks there are two OS 9 systems on one partition and if I pick the wrong one, the s...

Programmers needed for a new OS
Hi I search some programmers able to build an OS. here is my project: http://futurism.freepgs.com If you know a good place to ask this question, email me: jonano@gmail.com I really need coders for this new project. It is open source. --Jon jonano@gmail.com wrote: > Hi > > I search some programmers able to build an OS. > > here is my project: > > http://futurism.freepgs.com > > If you know a good place to ask this question, email me: > jonano@gmail.com > > I really need coders for this new project. It is open source. This is even better than To...

OS X server woes
Ah the joys of administering a server... We ahve an OS X server (we've had it for about a year) that we took the time to really figure out this past summer. Now that the school year has begun, we're wishing we could go back to the good old days of ASIP, sort of. The features are great, but the thing keeps crashing. It's a DP 1 GHz mirrored door tower with 512 MB of RAM. We have about 425 users, and 6 groups. There are about 60 client computers configured to get their setings from Workgroup Manager. Now that we finally have gotten all the client/user bugs ironed out, the thi...

New OS X Programmer
Hey all. I just purchased a powerbook a couple weeks ago, and a interested in learning macos programming. I know a bit of c, and a bi of java, as well as some other stuff like perl and php. From what i'v heard, most people seem to think Cocoa with objective c is the best wa for beginners.... Can anyone point me in the direction of any goo resources such as books or websites for me to start with? Like i sai i know C very superficially and know objective c almost none at all. Thanks in advance - iva ----------------------------------------------------------------------- Poste...

Woe and thrice woe...
I'd love to be able to just go to my keyboard/modules, turn them on and play and then quickly record something inspiring... Am I being to simplistic?? Sad fact is, that since my Atari ST /Pro24/Cubase 3 days I can't. Back then, I simply had a Roland Alpha Juno and MT32 module - simple. Recently however, I wanted to use an old Thinkpad (760 with built-in MIDI interface 133Mhz/104Mb) to run lowly Cbase 24 VST under W98 to replicate the Atari setup, but after failure with 3 midi interfaces - parallel, native MIDI/joystick port and USB via a pcmcia usb interface - I get same problems i...

Lifedrive/Mac OS X woes
I wonder if anyone here can help me with this? I had MissingSync working nicely with my iLife apps, then all of a sudden it crashes with the following message: Date/Time: 2007-03-27 09:48:14.273 +0200 OS Version: 10.4.8 (Build 8L127) Report Version: 4 Command: Missing Sync for Palm OS Path: /Applications/Missing Sync for Palm OS/Missing Sync for Palm OS.app/Contents/MacOS/Missing Sync for Palm OS Parent: WindowServer [66] Version: 5.1.2 (140) PID: 25895 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000007 I've trie...

Programmers needed for a new OS #2
Hi I search some programmers able to build an OS. here is my project: http://futurism.freepgs.com If you know a good place to ask this question, email me: jonano@gmail.com I really need coders for this new project. It is open source. --Jon On Jan 31, 4:52 am, jon...@gmail.com wrote: > Hi > > I search some programmers able to build an OS. > > here is my project: > > http://futurism.freepgs.com > > If you know a good place to ask this question, email me: > jon...@gmail.com > > I really need coders for this new project. It is open source. Before you ne...

Mac OS X configuration woes
Hello, Sorry for the repetitive post, but I've scoured all of the Mac Ruby pages and still haven't found a solution to my issue. Up to date version of Tiger. I have 1.8.4 installed. ruby -v yields: ruby 1.8.4 (2005-12-24) [powerpc-darwin8.4.0] I have gem installed. gem -v gives me: 0.8.11 gem env outputs: Rubygems Environment: - VERSION: 0.8.11 (0.8.11) - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.8 - GEM PATH: - /opt/local/lib/ruby/gems/1.8 - REMOTE SOURCES: - http://gems.rubyforge.org gem list outputs: actionmailer (1.1.5) Service layer for eas...

Web resources about - WinStartApp woes - comp.os.os2.programmer.misc

Resources last updated: 1/31/2016 8:19:15 AM