Hi Erik,
First, one comment: tasks are not "true" (kernel) threads. Currently a julia
process is single-threaded. Tasks are better considered as a form of
cooperative multitasking.
Yes, I've also found that I/O causes task switching. I don't personally know a
great way around this. One option would presumably be to have some form of
message queue; I am pretty sure that push!ing a new message on it---as long as
you don't need to touch I/O to create the message---would not cause a switch.
You can also use time() and other markers to indicate the status of control
flow.
I haven't been reading things carefully enough to know whether there's any
history behind this, but if you haven't said so already...what does gdb (or
equivalent) say about the segfault?
--Tim
On Saturday, September 20, 2014 08:24:59 PM Erik Schnetter wrote:
> I am trying to track down a segfault in a Julia application. Currently I am
> zooming in on "deserialize", as avoiding calling it seems to reliably cure
> the problem, while calling it (even if not using the result) seems to
> reliably trigger the segfault.
>
> I am using many threads (tasks), and deserialize is called concurrently. Is
> this safe? I've been bitten in the past by this; e.g. I've accidentally
> added an "info" statement into a sequence of statements that needs to be
> atomic, and I/O apparently switches threads. Is there a list of
> known-to-be-safe or known-to-be-unsafe functions? Is deserialization
> thread-safe in this respect?
>
> I am in particular deserializing function calls and lambda expressions, and
> I see global variables ("lambda_numbers", "known_lambda_data"). Are the
> respective data structures (WeakKeyDict and Dict) thread-safe?
>
> Is there a locking mechanism in Julia? This would temporarily only allow a
> single thread (task) to run, aborting with an error if this thread becomes
> unrunnable. In other words, calling "yield" when holding a lock would be a
> no-op.
>
> -erik
