Home » Eclipse Projects » Standard Widget Toolkit (SWT) » When to use multi-UI threading ?
| When to use multi-UI threading ? [message #448540] |
Tue, 11 January 2005 20:01  |
Eclipse User |
|
|
|
Originally posted by: atomotsugu.yahoo.com
Hi, I am beginning work on a system where we want to host multiple
software components running concurrently, each with at least one GUI
element and one thread. The components would be separately and
independently developed.
I am looking for some guidance on GUI event control. I'm relatively new
to SWT and RCP, but have used Swing for years. My starting position is
that the single event queue model is appropriate for this application.
However, I'd like to know what circumstances might make the multi-UI
thread model viable.
Using SWT's default (single) apartment thread model, I guess we'd need a
master component or infrastructure piece to own the one Display, and
each component could write to the GUI with asyncExec/syncExec calls.
With the free (multi) thread model, each component would have its own
event loop. The Eclipse help file has a paragraph about how SWT allows
for this:
-----
Note: The most common threading model for an SWT application is to run
a single UI thread and perform long operations in computational threads.
However, SWT does not restrict developers to this model. An application
could run multiple UI-threads with a separate event loop in each thread.
[from "Threading Issues" in Platform Plug-in Development]
-----
Where would I find more info on this topic ? Among other things, I am
wondering what the multiple instances of Display do to share the screen
real estate. Is it simply a matter of co-ordinating the locations and
dimensions of all Shell instances owned by the Displays ? It seems it
could get quite complex.
Oh yes, and we would be using RCP as the base, on Linux and Windows.
Thanks,
Al
|
|
|
| Re: When to use multi-UI threading ? [message #448633 is a reply to message #448540] |
Wed, 12 January 2005 16:13  |
 Steve Northover
Messages: 1636
Registered: July 2009 |
Senior Member |
|
|
Avoid multiple Displays. It's not supported on all platforms.
"tanuki" <atomotsugu@yahoo.com> wrote in message
news:cs1bbf$m1u$3@www.eclipse.org...
> Hi, I am beginning work on a system where we want to host multiple
> software components running concurrently, each with at least one GUI
> element and one thread. The components would be separately and
> independently developed.
>
> I am looking for some guidance on GUI event control. I'm relatively new
> to SWT and RCP, but have used Swing for years. My starting position is
> that the single event queue model is appropriate for this application.
> However, I'd like to know what circumstances might make the multi-UI
> thread model viable.
>
> Using SWT's default (single) apartment thread model, I guess we'd need a
> master component or infrastructure piece to own the one Display, and
> each component could write to the GUI with asyncExec/syncExec calls.
>
> With the free (multi) thread model, each component would have its own
> event loop. The Eclipse help file has a paragraph about how SWT allows
> for this:
>
> -----
> Note: The most common threading model for an SWT application is to run
> a single UI thread and perform long operations in computational threads.
> However, SWT does not restrict developers to this model. An application
> could run multiple UI-threads with a separate event loop in each thread.
> [from "Threading Issues" in Platform Plug-in Development]
> -----
>
> Where would I find more info on this topic ? Among other things, I am
> wondering what the multiple instances of Display do to share the screen
> real estate. Is it simply a matter of co-ordinating the locations and
> dimensions of all Shell instances owned by the Displays ? It seems it
> could get quite complex.
>
> Oh yes, and we would be using RCP as the base, on Linux and Windows.
>
>
> Thanks,
> Al
|
|
|
| Re: When to use multi-UI threading ? [message #448643 is a reply to message #448633] |
Wed, 12 January 2005 18:58 |
| Eclipse User |
|
|
|
Originally posted by: atomotsugu.yahoo.com
OK, I get your drift. If pressed though, would I be correct to tell
people that Linux and Windows do support this ?
Thanks
Al
Steve Northover wrote:
> Avoid multiple Displays. It's not supported on all platforms.
>
> "tanuki" <atomotsugu@yahoo.com> wrote in message
> news:cs1bbf$m1u$3@www.eclipse.org...
>
>>Hi, I am beginning work on a system where we want to host multiple
>>software components running concurrently, each with at least one GUI
>>element and one thread. The components would be separately and
>>independently developed.
>>
>>I am looking for some guidance on GUI event control. I'm relatively new
>>to SWT and RCP, but have used Swing for years. My starting position is
>>that the single event queue model is appropriate for this application.
>>However, I'd like to know what circumstances might make the multi-UI
>>thread model viable.
>>
>>Using SWT's default (single) apartment thread model, I guess we'd need a
>>master component or infrastructure piece to own the one Display, and
>>each component could write to the GUI with asyncExec/syncExec calls.
>>
>>With the free (multi) thread model, each component would have its own
>>event loop. The Eclipse help file has a paragraph about how SWT allows
>>for this:
>>
>>-----
>>Note: The most common threading model for an SWT application is to run
>>a single UI thread and perform long operations in computational threads.
>>However, SWT does not restrict developers to this model. An application
>>could run multiple UI-threads with a separate event loop in each thread.
>>[from "Threading Issues" in Platform Plug-in Development]
>>-----
>>
>>Where would I find more info on this topic ? Among other things, I am
>>wondering what the multiple instances of Display do to share the screen
>>real estate. Is it simply a matter of co-ordinating the locations and
>>dimensions of all Shell instances owned by the Displays ? It seems it
>>could get quite complex.
>>
>>Oh yes, and we would be using RCP as the base, on Linux and Windows.
>>
>>
>>Thanks,
>>Al
>
>
>
|
|
|
| Re: When to use multi-UI threading ? [message #449008 is a reply to message #448643] |
Mon, 17 January 2005 17:37 |
Steve Northover
Messages: 1636
Registered: July 2009 |
Senior Member |
|
|
Motif and Windows. GTK supports this but SWT hasn't been changed to use it.
"tanuki" <atomotsugu@yahoo.com> wrote in message
news:cs3s08$v18$1@www.eclipse.org...
> OK, I get your drift. If pressed though, would I be correct to tell
> people that Linux and Windows do support this ?
>
> Thanks
> Al
>
>
> Steve Northover wrote:
> > Avoid multiple Displays. It's not supported on all platforms.
> >
> > "tanuki" <atomotsugu@yahoo.com> wrote in message
> > news:cs1bbf$m1u$3@www.eclipse.org...
> >
> >>Hi, I am beginning work on a system where we want to host multiple
> >>software components running concurrently, each with at least one GUI
> >>element and one thread. The components would be separately and
> >>independently developed.
> >>
> >>I am looking for some guidance on GUI event control. I'm relatively new
> >>to SWT and RCP, but have used Swing for years. My starting position is
> >>that the single event queue model is appropriate for this application.
> >>However, I'd like to know what circumstances might make the multi-UI
> >>thread model viable.
> >>
> >>Using SWT's default (single) apartment thread model, I guess we'd need a
> >>master component or infrastructure piece to own the one Display, and
> >>each component could write to the GUI with asyncExec/syncExec calls.
> >>
> >>With the free (multi) thread model, each component would have its own
> >>event loop. The Eclipse help file has a paragraph about how SWT allows
> >>for this:
> >>
> >>-----
> >>Note: The most common threading model for an SWT application is to run
> >>a single UI thread and perform long operations in computational threads.
> >>However, SWT does not restrict developers to this model. An application
> >>could run multiple UI-threads with a separate event loop in each thread.
> >>[from "Threading Issues" in Platform Plug-in Development]
> >>-----
> >>
> >>Where would I find more info on this topic ? Among other things, I am
> >>wondering what the multiple instances of Display do to share the screen
> >>real estate. Is it simply a matter of co-ordinating the locations and
> >>dimensions of all Shell instances owned by the Displays ? It seems it
> >>could get quite complex.
> >>
> >>Oh yes, and we would be using RCP as the base, on Linux and Windows.
> >>
> >>
> >>Thanks,
> >>Al
> >
> >
> >
|
|
|
Goto Forum:
Current Time: Tue Apr 23 06:43:06 GMT 2024
Powered by FUDForum. Page generated in 0.03353 seconds |
] 
Search
Help
Register
Login
Home
