Phil Dawes wrote:
> 
> Yes that's what I'm currently doing. The problem is that this only works 
> for one target vm and I need it to work for many clients.
> (i.e. currently only one vm can be listening to the IOCompletionPort on 
> the write handle). I'm going to have a bit of a play tonight to see if 
> there's a way round this.

I couldn't figure out how to get the same handle to register with 
multiple IO completion ports, so I ended up writing a 
<synchronous-output-port> type that uses WriteFile with no overlapped IO.

Cheers,

Phil


TUPLE: synchronous-output-port < output-port ;

: <synchronous-output-port> ( handle -- output-port )
     synchronous-output-port <buffered-port> ;

: write-synchronously ( port -- n )
     make-FileArgs dup setup-write WriteFile drop lpNumberOfBytesRet>> 
first ;

M: synchronous-output-port stream-flush ( port -- )
     [
         dup buffer>> buffer-empty?
         [ drop ]
         [
             [ write-synchronously ]
             [ finish-write ]
             [ port-flush ] tri ] if
     ] with-destructors ;

> 
>>
>> PS Sorry if this is going down the wrong track. I'm still not
>> completely sure how the pipe stuff would work at a user level. There's
>> no example in native-thread-test.factor (for obvious reasons, I
>> guess...). Could you give a quick example of how user code would
>> ultimately use this feature?
>>
> 
> User api will be something like:
> 
> : spawn-vm ( quot -- msg-node )
> 
> i.e. you pass it a quot to execute in the new vm and it returns a 
> concurrency.messaging node that you can send messages to.
> 
> Under the hood the spawn-vm call initialises the vm pipe (if it's not 
> already created) spawns a new vm in a native thread and passes it the 
> 'write' end of the pipe and a lock. The new vm thread initialises its 
> own pipe, and pushes the write end of this new pipe down the parent pipe 
> to the parent.
> 
> Meanwhile both vms spawn a coop thread to continually read their pipe 
> and dispatch messages to local coop threads in the same manner as 
> concurrency.distributed.
> 
> Hope that makes sense,
> 
> Cheers,
> 
> Phil
> 


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to