Paul Moore wrote:
On the other hand, if the API is
create-vm ( startup-args -- vm )
then you get back a VM handle, which the calling thread can use how it
likes. With a suitable
get-pipe ( vm -- write-pipe read-pipe )
call, you can (allocate and) get the necessary pipe
Paul Moore wrote:
2009/10/25 Phil Dawes p...@phildawes.net:
I like the on-demand idea but unfortunately at the moment all we have is
the ability to pass startup args to the new vm. So vm A creates vm B and
gets to pass some (command line) args to it, there's no mechanism where
A can ask for a
2009/10/27 Phil Dawes p...@phildawes.net:
Paul Moore wrote:
Hmm, no I thought I understood this, but I don't really. You're saying
that the current API is something along the lines of
create-vm ( startup-args -- )
How's that any better than spawning a completely new Factor process?
Paul Moore wrote:
Just a thought - I wonder how hard it would be to implement some sort
of fork-like API at the factor level, using multiple VMs and threads
on Windows? Perl did something like that with their threading support,
I believe. Probably the biggest issue would be duplicating the
Phil,
Factor already has the ability to communicate with another server
remotely using TCP/IP. Why not use this to initiate communication with a
native VM thread and negotiate to use a fd descriptor as the
communication method afterwards hence bypassing TCP/IP. This way you can
come up with a
On Mon, Oct 26, 2009 at 8:37 PM, Bruce Breeanna Rennie
bren...@dcsi.net.au wrote:
Factor already has the ability to communicate with another server
remotely using TCP/IP.
There's a concurrency.distributed vocab allowing sending messages
between VM's (uses sockets). Also a channels.remote
Joe Groff wrote:
On Sun, Oct 25, 2009 at 3:19 PM, Phil Dawes p...@phildawes.net wrote:
I like the on-demand idea but unfortunately at the moment all we have is
the ability to pass startup args to the new vm. So vm A creates vm B and
gets to pass some (command line) args to it, there's no
2009/10/25 Phil Dawes p...@phildawes.net:
I like the on-demand idea but unfortunately at the moment all we have is
the ability to pass startup args to the new vm. So vm A creates vm B and
gets to pass some (command line) args to it, there's no mechanism where
A can ask for a new pipe handle
Hi Slava,
Slava Pestov wrote:
No native mutex is needed if you have a pair of pipes between every
two VMs that need to communicate. Then, one VM thread writes to the
pipe, another VM thread reads from it. Since a VM thread is so
heavy-weight (it has its own data heap) opening a handful of
No native mutex is needed if you have a pair of pipes between every
two VMs that need to communicate. Then, one VM thread writes to the
pipe, another VM thread reads from it. Since a VM thread is so
heavy-weight (it has its own data heap) opening a handful of pipes is
nothing.
What you do need
Hi Slava, Hi Everyone,
I got pretty far using pipes for native thread messaging on win and unix
last night (passing the receive fd/HANDLE to the new vm) before
realising that pipes won't handle concurrency between communicating vms.
Gah!
Does anybody have an idea for an easy implementation
On Fri, Oct 23, 2009 at 4:13 AM, Phil Dawes p...@phildawes.net wrote:
Hi Slava, Hi Everyone,
I got pretty far using pipes for native thread messaging on win and unix
last night (passing the receive fd/HANDLE to the new vm) before
realising that pipes won't handle concurrency between
Slava Pestov wrote:
On Fri, Oct 23, 2009 at 4:13 AM, Phil Dawes p...@phildawes.net wrote:
Hi Slava, Hi Everyone,
I got pretty far using pipes for native thread messaging on win and unix
last night (passing the receive fd/HANDLE to the new vm) before
realising that pipes won't handle
On Fri, Oct 23, 2009 at 5:22 AM, Phil Dawes p...@phildawes.net wrote:
If multiple producers try to send messages down the same pipe there's no
concurrency control so the data gets interleaved and corrupted.
Am I missing something?
Why not lock the pipe?
Slava
Slava Pestov wrote:
On Fri, Oct 23, 2009 at 5:22 AM, Phil Dawes p...@phildawes.net wrote:
If multiple producers try to send messages down the same pipe there's no
concurrency control so the data gets interleaved and corrupted.
Am I missing something?
Why not lock the pipe?
Makes sense. I
15 matches
Mail list logo
