_destroy functions might need foreign import safe?

[JackKelly-Bellroy]

We recently had an alarm in one of our Kafka producers caused by an AWS Lambda Function apparently crashing with this message:

bootstrap: schedule: re-entered unsafely.
Perhaps a 'foreign import unsafe' should be 'safe'? 

(Context: We statically link Haskell binaries using hw-kafka-client and run them on AWS Lambda to produce Kafka records.)

This is the only place in hw-kafka-client where I can see foreign import unsafe:

hw-kafka-client/src/Kafka/Internal/RdKafka.chs

Lines 273 to 276 in 17451f5

	foreign import ccall unsafe "rdkafka.h &rd_kafka_topic_partition_list_destroy"
	rdKafkaTopicPartitionListDestroyF :: FinalizerPtr RdKafkaTopicPartitionListT
	foreign import ccall unsafe "rdkafka.h rd_kafka_topic_partition_list_destroy"
	rdKafkaTopicPartitionListDestroy :: Ptr RdKafkaTopicPartitionListT -> IO ()

Lambda periodically terminates and re-launches binaries, even if they're running well, to "keep the execution environments fresh". One possible hypothesis, though I don't know FFI-level stuff that well: is it possible for the binary to have been put to sleep by the Lambda service (which either suspends the microVM or stops the process, possibly both?) inside an FFI call, then a SIGTERM causes finalisers to begin running while still inside the FFI call?

Should these be made foreign import safe?

[AlexeyRaga]

I had that one previously, but very rarely and I wasn't able to figure out where it came from.
I don't remember what I tried though. I believe that I did try making things safe/unsafe... Which ones - don't know :)

[lrworth]

As explained in #204, we removed all the unsafe markings and still saw that schedule: re-entered unsafely error; so this issue may be unrelated to hw-kafka-client.

[JackKelly-Bellroy]

To be clear in case someone else finds this, we had forgotten to enable -threaded on certain binaries, and this seems to have made the problem go away.