lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> So all of them are in a pending linda receive operation. Therefore, as per documentation, their status should be "waiting". But in fact they are "running". Am I missing something obvious?

I got a peek at the code, and it is totally understandable, since nowhere is the lane status changed from RUNNING to WAITING and back on linda operations. The thing is, unless I am mistaken, linda:send() and linda:receive() implementations don't have a readily available access to the lane they are run in. I have hijacked the pointer stored in the CANCEL_TEST_KEY registry entry of the lane's state to grab it, as follows (copied from cancel_test's code):

LUAG_FUNC( linda_receive ) {

            } else {    /* nothing received; wait until timeout */
                cancel= cancel_test( L );   // testing here causes no delays
                if (cancel) break;

                // Release the K lock for the duration of wait, and re-acquire
                // BBB HACK: fetch the lane object to update the status
                    struct s_lane *s;
                    enum e_status prev_status;

                    lua_pushlightuserdata( L, CANCEL_TEST_KEY );
                    lua_rawget( L, LUA_REGISTRYINDEX );
                    s= lua_touserdata( L, -1 );     // lightuserdata (true 's_lane' pointer) / nil
                    if( s)
                        prev_status = s->status;
                        s->status = WAITING;
                    if (!SIGNAL_WAIT( &linda->write_happened, &K->lock_, timeout ))
                        if( s) s->status = prev_status;
                    if( s) s->status = prev_status;

It seems to result in the desirable behaviour, but maybe there are some corner cases I missed? I'd appreciate knowledgeable insight on the subject :-)