Lime isn't thread safe?

vroad · April 17, 2016, 12:02pm

I asked about this before in issue tracker, but no one answered this question, so I closed that and asking here.

It seems possible to access lime’s CFFI functions from multiple threads, but doing this may lead to unexpected behavior because they are accessing global variables without locks or memory barriers. It might be very rare to happen, but it will happen I guess.

I think that moving all val_id initialization to one place will solve this problem, though this would need lots of refactoring.

github.com

openfl/lime/blob/a9bed580b337529e517ee432c2ea41d1c00aab49/project/src/graphics/ImageBuffer.cpp#L117-L129


		if (!init) {
			
			id_bitsPerPixel = val_id ("bitsPerPixel");
			id_transparent = val_id ("transparent");
			id_buffer = val_id ("buffer");
			id_data = val_id ("data");
			id_width = val_id ("width");
			id_height = val_id ("height");
			id_format = val_id ("format");
			id_premultiplied = val_id ("premultiplied");
			init = true;
			
		}

val_id also doesn’t seem to be thread safe, at least on hxcpp. It’s also accessing global variables without locks.

github.com

HaxeFoundation/hxcpp/blob/d010e5131c415b19f57981718e2b0a819d8ff772/src/hx/StdLibs.cpp#L674




const String &__hxcpp_field_from_id( int f )

{

if (!sgFieldToString)

   return sgNullString;



return sgFieldToString[f];

}





int  __hxcpp_field_to_id( const char *inFieldName )

{

if (!sgFieldToStringAlloc)

{

   sgFieldToStringAlloc = 100;

   sgFieldToString = (String *)malloc(sgFieldToStringAlloc * sizeof(String));



   sgStringToField = new StringToField;

}



std::string f(inFieldName);