linked-in drivers once again

[per@REDACTED]

Raimo Niskanen <raimo@REDACTED> wrote:
>
>Vance Shipley wrote:
>> 
>> Why the former works is a fluke.  
>
>A fluke and an ugly behaviour with open_port/2. The function
>open_port({spawn, Command}, []) was originally used for opening a port
>that communicates with an external program - Command, and then reused
>for opening a port that is an instance of a port driver - Command.

Actually I think it's a feature (I may even be to blame for it:-) - it
allows you to change from external program to driver (which is really
just an "implementation detail", right:-) or vice versa without changing
the Erlang code - or have the same Erlang code on different OSes even
though one uses an external program and another a driver (for whatever
OS-specific reason).

> So we
>have a namespace clash here. If there exists a port driver named 'foo'
>you cannot call an external program (port program) named 'foo' - it is
>shadowed by the driver (or is it the other way around?)

Well, not quite - you can always call the external program with the full
pathname, which is often the best thing to do if it is specific to your
application - and if you don't, you have plenty of opportunity for
shadowing in your $PATH anyway...

>What probably happens in "the former case" is that a port is opened (an
>instance of the built in 'spawn' driver) that tries to execute
>"./easiest_drv.so" in another unix process, which fails and the port
>dies. Therefore you get a port, but it is closed when you try to use it.

I like that explanation better than Vance's:-) - the C semantics specify
that static variables are initialized to zero... (unless an initial
value is given, of course).

--Per Hedeland
per@REDACTED