RE: Thanks - Threads

new topic     » topic index » view thread      » older message » newer message

Actually.... after pondering possible implementation of threads, I had an 
idea... what does the list think of this:

I thought hey, wouldn't it be nice to call functions and procs and have it 
return immediately to the calling process, and have the sub proceed 
independantly, like a thread? Rationalising... a function couldn't possibly 
work, cause the calling function depends on the value that is returned.... 
and a thread never returns, it just ends...

Well, what about adding a third subroutine? Call it thread or something.
It's given certain parameters, and called like a normal procedure... however 
the parent continues after that, and the thread subroutine continues in 
parallel... when it finishes, it doesn't go back to the parent, cause the 
parent's moved on. It just stops.

Okay, possible problems:

1. Race Conditions:

Well, we would need to have support for semaphores added, at least. signal 
and wait could act on normal euphoria integers. Other multi-processing 
things can be discussed.....

2. Existing code:

If a thread calls a library function, there are no guaruntees as to what 
that code would do if it wasn't written with concurrency in mind... So, we 
need to safeguard the integrity of the library's data. If there are two 
threads that both call a function or try and change the data in the same 
library, then whichever one gets there first does so without problems, and 
the other is suspended until the first thread finishes. That way, no old 
code will be broken.

Of course, some libraries may *want* concurrent access, and will be capable 
of handling multiple threads accessing it at the same time. Allow that to 
happen if the library has a "with concurrent" call at the top.

3. Ummm...

I don't know...



Shoot some holes in my arguments, please.
(sorry for double post)
=====================================================
.______<-------------------\__
/ _____<--------------------__|===
||_    <-------------------/
\__| Mr Trick





>From: Jonas  Temple <jtemple at yhti.net>
>Reply-To: EUforum at topica.com
>To: EUforum <EUforum at topica.com>
>Subject: RE: Thanks
>Date: Wed, 18 Jun 2003 13:08:04 +0000
>
>
>That's why I've asked Rob in the past about the possibility of threads
>in Eu.  I've got some programs that could really benefit from having
>threads.
>
>I'll keep hoping...
>
>Jonas
>Martin Stachon wrote:
> >
> >
> > The problem is that Euphoria is not multi-threaded rather than in OS.
> > While we are doing a longer computation  (ie not returning from event
> > handler in win32lib), we cannot call ?GetNextMessage? (forgot the actual
> >
> > function name) and Windows are stacking up events in application queue.
> > But Windows require the application to handle the event. For example, if
> >
> > you move a window, WM_MOVE message is issued, but until your application
> >
> > process the message, the window is not actually moved (the application
> > may say it cannot be moved). The OS could possibly have timeouts for
> > events, and do default processing after timeout, but you would loose a
> > lot of user's actions when high CPU load or application being busy.
> >
> > If we had at least two threads, win32lib would set up separate thread
> > just to handle window events, but the way it is we must call doEvents()
> > occasionaly in longer code to handle event queue.
> >
> >     Martin
> >
>
>
>
>TOPICA - Start your own email discussion group. FREE!
>
>

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu