Asynchronous ODBC

[Michael McDaniel]

Basically, spawned processes run independently (with certain caveats according
to how it was started (spawn, spawn_link, etc.) and child/parent
relationships).  If I do not need direct return information from a slow fun()
then I will spawn it and let it do its thing in the background.  


For more details of operation, see the 'Gettting Started' section of the
Erlang docs, particularly section 3, Concurrent Programming.

Here's a good spot to see: http://www.erlang.org/starting.html


On my system with documentation installed, I point my browser here:

   file:///usr/local/lib/erlang/doc/getting_started/part_frame.html


~Michael



On Wed, May 31, 2006 at 02:17:14PM -0600, Michael FIG wrote:
> Hi,
> 
> >> imho it would be sufficient to have the wrapper in another process 
> >> (created by erlang:spawn/1). there is no need to involve another node.
> >> please accept my apology if i have misunderstood something.
> >
> >I agree with bengt (with, apparently, the same understanding of your
> >question).
> 
> Ahh.  I think I see now.  I was under the mistaken understanding that all other processes on a node block during gen_server:call.  Now I think I understand that any "receive", no matter how deeply nested, allows other processes to run.  So then the "spawn"ed wrapper just insulates the caller from the process that blocks during gen_server:call.
> 
> Is that correct?  If so, then that's really good, and finally an escape from the nuisances of event-driven programming (my experience with Visual Basic 6, where DoEvents was truly horrid... you'd either reenter your code or blow up the stack if you aren't careful).
> 
> Nice.
> 
> -- 
> Michael FIG <fig@REDACTED>, PMP
> VP Technology
> MarkeTel Multi-Line Dialing Systems, Ltd.
> Phone: (306) 359-6893 ext. 528
> 

-- 
Michael McDaniel
Portland, Oregon, USA
+1 503 283 5284
http://autosys.us