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 th
2009/10/27 Phil Dawes :
> 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?
>>
>
> Goo
Paul Moore wrote:
> 2009/10/25 Phil Dawes :
>> 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
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
2009/10/25 Phil Dawes :
> 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 from B.
Hmm, no
Joe Groff wrote:
> On Sun, Oct 25, 2009 at 3:19 PM, Phil Dawes 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 mechanism where
>
On Mon, Oct 26, 2009 at 8:37 PM, Bruce & Breeanna Rennie
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 which is currently
br
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 Sun, Oct 25, 2009 at 3:19 PM, Phil Dawes 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 mechanism where
> A can ask for a new p
2009/10/25 Phil Dawes :
> 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 from B.
>
> Of co
Hi Paul,
Paul Moore wrote:
> 2009/10/25 Phil Dawes :
>>
>> I thought about the n^2 pipes option, but thought that the bootstrap
>> would be a bit of a pita: Each time a new vm starts all the others have
>> to coordinate and listen on new pipes.
>
> Would this work?
>
> If VM A needs to communica
2009/10/25 Phil Dawes :
> 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
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 for
Slava Pestov wrote:
> On Fri, Oct 23, 2009 at 5:22 AM, Phil Dawes 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 was hopi
On Fri, Oct 23, 2009 at 5:22 AM, Phil Dawes 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 4:13 AM, Phil Dawes 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 betw
On Fri, Oct 23, 2009 at 4:13 AM, Phil Dawes 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 communicating vms.
> Ga
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 her
19 matches
Mail list logo
