1. Simulating Threads in Eu
I'm trying to figure out how to simulate
threads in Eu, under Linux fork() does what I need
but the problem is with sharing veriables.
(I could use clone(), but besides being Linux-only
(iow, clone() WILL NOT WORK FOR FREEBSD) it
has the requirement that exu itself be re-entrant.
I dont need exu to be re-entrant (I plan to use fork()
to separate the "threads" from each other) but I do need
a way for simulating the sharing of variables (i'll
also make a preprocessor once i got the basic libs
down to simpify the writing of the code). I could use
shared memory, but there is no way to share sequences.
Anyone have any ideas whatsoever? (I did try
using files but that was too clumsy, I may
look into it again if no one can give me
a better alternative.)
TIA,
jbrown
--
http://fastmail.fm
- Ever wonder why we aren't named snailmail.sm?
2. Re: Simulating Threads in Eu
jbrown writes:
> I'm trying to figure out how to simulate
> threads in Eu, under Linux fork() does what I need
> but the problem is with sharing veriables.
Linux (Unix) shared memory is probably what you are looking for.
(type: man shmat)
That would give multiple Euphoria processes a fast way
of sharing data in memory, at a low level via peeks and pokes.
If you want to share complex sequences, you could easily adapt the
compress() and decompress() routines in database.e to
convert any Euphoria sequence or atom to/from a string of bytes in memory.
You could pre-allocate the data or write a storage allocator to
give out blocks of shared memory on demand.
Concurrency issues (critical sections) can be handled
using UNIX semaphores (man semget). Processes would
have to call a routine whenever they wanted to read or
write a "variable" in shared memory, but it would be much faster
than using files.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Simulating Threads in Eu
After thinking a lot, i can't find another way than sharing memory or
doing it by file... on windows i could start another eu4 instance and
send messages like one of my libs does, but i don't have too much
knowledge about this on linux.
Best Regards,
Guillermo Bonvehi
--- jbrown105 at speedymail.org wrote:
>
> I'm trying to figure out how to simulate
> threads in Eu, under Linux fork() does what I need
> but the problem is with sharing veriables.
> (I could use clone(), but besides being Linux-only
> (iow, clone() WILL NOT WORK FOR FREEBSD) it
> has the requirement that exu itself be re-entrant.
> I dont need exu to be re-entrant (I plan to use fork()
> to separate the "threads" from each other) but I do need
> a way for simulating the sharing of variables (i'll
> also make a preprocessor once i got the basic libs
> down to simpify the writing of the code). I could use
> shared memory, but there is no way to share sequences.
> Anyone have any ideas whatsoever? (I did try
> using files but that was too clumsy, I may
> look into it again if no one can give me
> a better alternative.)
>
> TIA,
> jbrown
>
>
>
> --
> http://fastmail.fm
> - Ever wonder why we aren't named snailmail.sm?
>
>
>
>
4. Re: Simulating Threads in Eu
On 0, Robert Craig <rds at RapidEuphoria.com> wrote:
>
> jbrown writes:
> > I'm trying to figure out how to simulate
> > threads in Eu, under Linux fork() does what I need
> > but the problem is with sharing veriables.
>
> Linux (Unix) shared memory is probably what you are looking for.
> (type: man shmat)
>
> That would give multiple Euphoria processes a fast way
> of sharing data in memory, at a low level via peeks and pokes.
> If you want to share complex sequences, you could easily adapt the
> compress() and decompress() routines in database.e to
> convert any Euphoria sequence or atom to/from a string of bytes in memory.
> You could pre-allocate the data or write a storage allocator to
> give out blocks of shared memory on demand.
> Concurrency issues (critical sections) can be handled
> using UNIX semaphores (man semget). Processes would
> have to call a routine whenever they wanted to read or
> write a "variable" in shared memory, but it would be much faster
> than using files.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
I already have the shared memory routines wrapped, and semaphores
should be equally simple. The real problem was how to handle
complex sequences and how to allocate the shared memory dynamicly.
After looking at database.e, I can see how to share Euphoria objects
(although I'd rather modify bget/bprint into mget/print, which seems
simplier) but I still am unclear as how to allocate the memory for
variables
on demand and have all "threads" know about it simultaniously.
Once I can figure out how to do that then I can start coding this
project again.
jbrown
--
Faster than the email provider that you're using!
Soar with FastMail.FM! -> http://fastmail.fm
5. Re: Simulating Threads in Eu
jbrown writes:
> I still am unclear as how to allocate the memory for variables
> on demand and have all "threads" know about it simultaniously.
You can set up a heap in shared memory, and write your
own storage allocator for variable-sized blocks of memory.
It would look a lot like C's malloc() and free(), although
you should try to do a simple version to start with.
Each Euphoria process would have a copy of your routines for
allocating and freeing shared memory. You would definitely
need to do a semaphore operation at the entry and exit points of
your allocate() and free() routines to prevent multiple processes from
messing around with the heap at the same time. The control
variables for the heap, such as the pointer to the list of free blocks,
would be stored at known fixed offsets from the start of shared memory.
I did something like this on Unix a long time ago (before Euphoria).
It was lots of fun, but I don't have the C code anymore.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Simulating Threads in Eu
On 0, Robert Craig <rds at RapidEuphoria.com> wrote:
>
> jbrown writes:
> > I still am unclear as how to allocate the memory for variables
> > on demand and have all "threads" know about it simultaniously.
>
> You can set up a heap in shared memory, and write your
> own storage allocator for variable-sized blocks of memory.
> It would look a lot like C's malloc() and free(), although
> you should try to do a simple version to start with.
I think that instead, I will use shared memory to globally
hold one sequence, which has all the names and data values of
the shared "variables", as formatted via my custom version of
bprint().
> Each Euphoria process would have a copy of your routines for
> allocating and freeing shared memory. You would definitely
> need to do a semaphore operation at the entry and exit points of
> your allocate() and free() routines to prevent multiple processes from
> messing around with the heap at the same time. The control
> variables for the heap, such as the pointer to the list of free blocks,
> would be stored at known fixed offsets from the start of shared memory.
>
Hmm ... the lack of semaphores explains some of the strange errors
I've recived via file storage. I think I will release the lib with
2 files: one for using shared memory and one for using file i/o.
This would hopefully make the library more flexible.
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
jbrown
--
http://fastmail.fm
- In the time it takes you to read this, you could be FastMailing
