Threads
On Wed, Jun 18, 2003 at 11:44:57PM +1000, mistertrik at hotmail.com wrote:
>
>
> Actually.... after pondering possible implementation of threads, I had an
> idea... what does the list think of this:
I have a Linux emulation of threads for Eu. I'll compare how its implemented
to your ideas on how builtin support for it should be implemented.
>
> 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...
A procedure, however, would work just fine.
>
> 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.
Why not have a start_thread(routine_id("thread_proc")) routine builtin then?
>
> 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.....
>
I just have a type of shared "variable" to transfer data between threads;
it was very useful for emulating semaphores, mutexes, etc.
> 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.
>
Or simply have it that the private data/variables of 2 threads remain seperate
unless explicitly shared. This way the inherent difficulties of using threads in
C are reduced in Eu.
> =====================================================
> .______<-------------------\__
> / _____<--------------------__|===
> ||_ <-------------------/
> \__| 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!
> >
> >
jbrown
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
|
Not Categorized, Please Help
|
|
