1. Threads
- Posted by Craig Roberts <rwallieeyes at earthlink.net>
Nov 08, 2005
-
Last edited Nov 09, 2005
Does Euphoria support threads? I saw something about multi-tasking in some
messages, is this how Euphoria does it?
Regards,
CraigG
Answer: one.
Question: How many psychics does it take to change a light bulb.
2. Re: Threads
codepilot Gmail Account wrote:
> One time I wanted to make a web server, so I looked at some other
> ones, and some tutorials. I saw several ways to use winsock. I started
> with the blocking methods just because they seemed easiest. Then after
> only one connection at a time was possible, I started to think. At the
> time I was taking a C++ class at school so most the tutorials I looked
> at where C. I had been using euphoria for years by then, and wanted to
> do a euphoria web server. So I started to port a threaded web server
> tutorial to euphoria. And the threads did work, for a minute. Anytime
> I printed to the screen, it crashed, and randomly all the time. Then I
> read somewhere that euphoria wasn't thread-safe, and I was
> heart-broken. The language that was my favorite, and had used for
> years, and wrote lots of stuff in was not able to do something that I
> really wanted to do.
>
> So I gave up and wrote it in C. Then later I came back to it, and
> found the asyncselect command in winsock, and made it with win32lib in
> euphoria, and was kinda disappointed at the speed, but happy it was
> possible.
>
> So while everything may be possible in euphoria without threads, it
> kinda hurts that there not there when you want them. It hurts speed,
> algorithm choices, and even the user base, which I think would be
> bigger otherwise.
I think that's an important point. Porting code from "classic"
procedural languages such as C, Basic or Pascal shouldn't be too hard,
especially since many algorthms are already implemented in these
languages, and not in Euphoria. These considerations not only apply to
threads, but also to other things, for instance the 'continue' statement.
<big snip>
Regards,
Juergen
3. Re: Threads
This is a multi-part message in MIME format.
------=_NextPart_000_0043_01C27036.EBF45B40
charset="iso-8859-1"
I have found it very easy to trigger application-defined events in =
another window by registering a Windows Message using =
RegisterWindowMessage(). The routine takes a pointer to a =
null-terminated character-string as an argument to identify a unique =
system-wide message. Any other window that then uses that same string in =
a call to RegisterWindowMessage(), recieves the same value as the first =
did, to use as a window message. The message will remain system-wide for =
the duration of the windows session, I believe.
Since the routines in memshare.ew also take character-strings ( or even =
sequences, with limitations ) to identify a block of shared memory =
throughout the system, you can do some interesting things with the two. =
For Example:
Use shared-memory to sm_create() a block of shared memory using a =
file-name, even appending some string onto the file-name for better =
security (like "C:\database\myfile.dbf-Eu-Process"). Then use the shared =
memory to store the window-handle of the process that has access to the =
file, plus any other data you wish.
If another application wants to open the file, it can call sm_create(), =
which will fail if the memory is already allocated using that string =
(file-name). The second application can then sm_open() the block of =
memory, and read the window-handle of the first application, then use a =
unique window message to send a message to the first, requesting access, =
or the others read/write status, or whatever you need to do. You could =
even pass the window-handle of the second application in the unique =
windows message, and when the first application is done, it can =
PostMessage() a "file-released" message to the second.
In the very least it offers a way to flag, across the entire system, =
that a file is open by another application.
Jason
------=_NextPart_000_0043_01C27036.EBF45B40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I have found it very easy to trigger=20
application-defined events in another window by registering a Windows =
Message=20
using RegisterWindowMessage(). The routine takes a pointer to a =
null-terminated=20
character-string as an argument to identify a unique system-wide =
message. Any=20
other window that then uses that same string in a call to=20
RegisterWindowMessage(), recieves the same value as the first did, to =
use as a=20
window message. The message will remain system-wide for the =
duration of the=20
windows session, I believe.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Since the routines in memshare.ew also =
take=20
character-strings ( or even sequences, with limitations ) to =
identify a=20
block of shared memory throughout the system, you can do some =
interesting things=20
with the two. For Example:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Use shared-memory to sm_create() a =
block of shared=20
memory using a file-name, even appending some string onto the file-name =
for=20
better security (like "C:\database\myfile.dbf-Eu-Process"). Then use the =
shared=20
memory to store the window-handle of the process that has access to the =
file,=20
plus any other data you wish.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>If another application wants to open =
the file, it=20
can call sm_create(), which will fail if the memory is already allocated =
using=20
that string (file-name). The second application can then sm_open() the =
block of=20
memory, and read the window-handle of the first application, then =
use=20
a unique window message to send a message to the first, requesting =
access,=20
or the others read/write status, or whatever you need to do. You could =
even pass=20
the window-handle of the second application in the unique windows =
message,=20
and when the first application is done, it can PostMessage() a =
"file-released"=20
message to the second.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In the very least it offers a way to =
flag, across=20
the entire system, that a file is open by another =
application.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Jason</FONT></DIV>
------=_NextPart_000_0043_01C27036.EBF45B40--
4. Threads
Do you know somebody if an Euphoria interpreter is able to work with
multithread code. Can I use WIN32 CreateThread function in my code ?
Josef Jindra
5. 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
