A port is a program that communicates to the Erlang side using standard input output. Whether you need thread safety or not depends on the communication protocol you implement.
If you think in terms of a port being an erlang process (which for the erlang side is the abstraction your erlang code sees) you could implement a protocol whether for each request you send to it, it will block until it sends back a response, or that you could send several requests in parallel and get responses for all of them asynchronously.
Going the the C side, the implementation of the former case would be a simple loop doing
- read command from stdin
- process that command
- write result to stdout
- go to 1
The concurrency is handled in the erlang side as all incoming commands will pile up in the port inbox while the port is processing one at a time.
For the latter, you would need a mechanism to handle input messages git remote add origin [email protected]:samuelrivas/dfberl.git
asynchronously, I'll use threads here for simplicity:
The main loop:
- read command from stdin
- spawn a thread to process it
- go to 1
The thread loop:
- process command
- write result to stdout
Note that threads will need some kind of locking when writing to stdout, I usually implement that part as yet another thread with an asynchronous queue where all the other threads publish results to.
In the second scenario you will have concurrency in the C side, so you need to care about thread safety. In the first one the C side doesn't handle any concurrency, so thread safety is not a concern there.