[erlang-questions] How to exchange sensitive data with ports?

Michael Truog mjtruog@REDACTED
Sat Aug 8 20:17:22 CEST 2009


The port driver can be made to make async function calls however there
are some problems with doing this:
1) the port driver can not be unloaded to do a code swap (after the
first async port driver call), since it is safer to keep the code loaded
in case there is still a thread busy on an async request
2) the async thread pool takes a single thread count for all async
requests used by the erlang VM, so your async requests are competing
with file, crypto, and anything else that might choose to use the async
thread pool.  the async thread pool is implemented without a shared job
queue, so you are at the mercy of any jobs that got to the thread's
queue before your jobs.  However, by limiting your usage of the async
thread pool and setting the integer async thread pool limit high enough,
you should avoid any contention for threads.  Last time I looked, there
was an environment variable to limit the file module usage of async
calls, but I am not sure about the crypto usage of async calls... crypto
may not be doing async requests.

I did some code to automatically generate a port driver or port with
preprocessor expansion that might help.  To make a call async you can
change a 0 to a 1 in the header file that defines the function calls:
http://forum.trapexit.org/viewtopic.php?t=15118&sid=4174d776f9abc2b65ed145333e24886e
http://github.com/okeuday/generic-erlang-port--driver-/tree/master

Elena Garrulo wrote:
> 2009/8/8 Richard Andrews <bflatmaj7th@REDACTED>:
>   
>> On Sat, Aug 8, 2009 at 9:35 PM, Elena Garrulo<egarrulo@REDACTED> wrote:
>>     
>>> What if C calls are time consuming? Does whole Erlang VM stop until
>>> the C procedure returns?
>>>       
>> IIRC the "control" style driver would block but the IO style driver
>> model would not. I think this requires that there is another thread
>> somewhere which can issue a callback into erlang with a result. I've
>> never implemented one of these.
>>     
>
> That's what I was thinking about: making a worker thread handle the
> requests asynchronously, sending back the results when done. From your
> answer, I understand that is feasible, it's just not sketched into
> simpler (synchronous) examples.
>
>   
>>> And user? Can a user process watch another (same) user process?
>>>       
>> I don't think this is possible.
>>
>>     
>
> Well, that's what I did know about Windows, and wondered whether
> things were different under Linux.
>
> OK, here is my roadmap: first make the (simpler) ports solution work,
> then implementing it as linked-in driver.
>
> Thanks.
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
>   



More information about the erlang-questions mailing list