<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Simplest Linked-In Driver EVAH</title>
	<atom:link href="http://weblog.hypotheticalabs.com/?feed=rss2&#038;p=446" rel="self" type="application/rss+xml" />
	<link>http://weblog.hypotheticalabs.com/?p=446</link>
	<description>Improving the world, hypothetically</description>
	<lastBuildDate>Thu, 19 Aug 2010 15:28:34 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Matt Williamson</title>
		<link>http://weblog.hypotheticalabs.com/?p=446&#038;cpage=1#comment-2419</link>
		<dc:creator>Matt Williamson</dc:creator>
		<pubDate>Tue, 31 Mar 2009 14:42:13 +0000</pubDate>
		<guid isPermaLink="false">http://weblog.hypotheticalabs.com/?p=446#comment-2419</guid>
		<description>Thanks,  Kevin! I&#039;ve been meaning to try out linked in drivers for a while now.</description>
		<content:encoded><![CDATA[<p>Thanks,  Kevin! I&#8217;ve been meaning to try out linked in drivers for a while now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kevin</title>
		<link>http://weblog.hypotheticalabs.com/?p=446&#038;cpage=1#comment-2414</link>
		<dc:creator>kevin</dc:creator>
		<pubDate>Tue, 24 Mar 2009 19:52:53 +0000</pubDate>
		<guid isPermaLink="false">http://weblog.hypotheticalabs.com/?p=446#comment-2414</guid>
		<description>What @evgen said :)</description>
		<content:encoded><![CDATA[<p>What @evgen said :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: evgen</title>
		<link>http://weblog.hypotheticalabs.com/?p=446&#038;cpage=1#comment-2413</link>
		<dc:creator>evgen</dc:creator>
		<pubDate>Tue, 24 Mar 2009 16:52:53 +0000</pubDate>
		<guid isPermaLink="false">http://weblog.hypotheticalabs.com/?p=446#comment-2413</guid>
		<description>There are two ways to access external code in Erlang, via a linked-in driver or a port.  The difference between the two is that a linked-in driver runs in the Erlang VM process space and has much faster communication with the library (with the dangerous downside that a bug or crash in the driver will take down the VM) while a standard port runs in its own process space (safer) but uses a slower communication mechanism.

You can open multiple ports to the same linked in driver and get multiple instances of the driver which can sometimes increase throughput (e.g. the crypto module does this to create multiple instances of crypto routines that each maintain their own internal state for a particular crypto operation.)  In general the benefits of this are limited depending on the specifics of the library; it seems to be most frequently used with standard ports when you want several &quot;workers&quot; that have a bit of launch overhead (e.g. starting up multiple python interpreters if you are on a multi-core box.)

You can do anything you want inside the driver.  Depending on whether or not the driver is linked-in or not you might even be able to have the driver make calls directly into the Erlang VM.  A linked-in driver can do anything and get the data quickly to/from the other bits of the Erlang VM, but it can also crash the whole VM.  If you are using pthreads inside a linked-in driver you are probably doing something wrong :)</description>
		<content:encoded><![CDATA[<p>There are two ways to access external code in Erlang, via a linked-in driver or a port.  The difference between the two is that a linked-in driver runs in the Erlang VM process space and has much faster communication with the library (with the dangerous downside that a bug or crash in the driver will take down the VM) while a standard port runs in its own process space (safer) but uses a slower communication mechanism.</p>
<p>You can open multiple ports to the same linked in driver and get multiple instances of the driver which can sometimes increase throughput (e.g. the crypto module does this to create multiple instances of crypto routines that each maintain their own internal state for a particular crypto operation.)  In general the benefits of this are limited depending on the specifics of the library; it seems to be most frequently used with standard ports when you want several &#8220;workers&#8221; that have a bit of launch overhead (e.g. starting up multiple python interpreters if you are on a multi-core box.)</p>
<p>You can do anything you want inside the driver.  Depending on whether or not the driver is linked-in or not you might even be able to have the driver make calls directly into the Erlang VM.  A linked-in driver can do anything and get the data quickly to/from the other bits of the Erlang VM, but it can also crash the whole VM.  If you are using pthreads inside a linked-in driver you are probably doing something wrong :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harish Mallipeddi</title>
		<link>http://weblog.hypotheticalabs.com/?p=446&#038;cpage=1#comment-2412</link>
		<dc:creator>Harish Mallipeddi</dc:creator>
		<pubDate>Tue, 24 Mar 2009 14:37:42 +0000</pubDate>
		<guid isPermaLink="false">http://weblog.hypotheticalabs.com/?p=446#comment-2412</guid>
		<description>I&#039;ve a few questions about linked-in drivers:

* When you create a linked-in driver like above, what&#039;s going on underneath? The driver is loaded within that Erlang VM process space? Or does it spawn a child process?

* Can you open multiple ports (via open_port/2) to the same linked-in driver? If you do, what&#039;ll be the behavior? Is there a use-case for this?

* Can you use regular pthreads inside the driver? And can you spawn child procs? Basically can the linked-in driver do anything that an external C program can do, or are there any restrictions?</description>
		<content:encoded><![CDATA[<p>I&#8217;ve a few questions about linked-in drivers:</p>
<p>* When you create a linked-in driver like above, what&#8217;s going on underneath? The driver is loaded within that Erlang VM process space? Or does it spawn a child process?</p>
<p>* Can you open multiple ports (via open_port/2) to the same linked-in driver? If you do, what&#8217;ll be the behavior? Is there a use-case for this?</p>
<p>* Can you use regular pthreads inside the driver? And can you spawn child procs? Basically can the linked-in driver do anything that an external C program can do, or are there any restrictions?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
