[1.9.5 scriptext] Service.Contact thread doesn't terminate if contact found

[kohchunk]

Hi,
I have some problems with the scriptext Contacts service.
Using the example source code

import scriptext
import e32

# Using e32.Ao_lock() to make main function wait till callback is hit
lock = e32.Ao_lock()

# Callback function will be called when the requested service is complete
def get_list(trans_id, event_id, input_params):
    if event_id != scriptext.EventCompleted:   
        # Check the event status
        print "Error in retrieving required info"
        print "Error code is: " + str(input_params["ReturnValue"]["ErrorCode"])
        if "ErrorMessage" in input_params["ReturnValue"]:
            print "Error message:" + input_params["ReturnValue"]["ErrorMessage"]
    else:
        if 0 != input_params["ErrorCode"]:
            print "Failed: %d" % input_params["ErrorCode"]
        else:
            for contact in input_params["ReturnValue"]:
                name = u""
                # Create the name
                if "FirstName" in contact:
                    name += contact["FirstName"]["Value"]
                if "LastName" in contact:
                    if len(name) > 0:
                        name += u" "
                    name += contact["LastName"]["Value"]
            print "Name: " + name
    lock.signal()

# Load contacts module
contacts_handle = scriptext.load("Service.Contact", "IDataSource")

event_id = contacts_handle.call('GetList', {'Type': u'Contact', 'Filter':{'SearchVal': u'Tom'}}, callback=get_list)

print "Waiting for the request to be processed!"
lock.wait()
print "Request complete!"

If the contact "Tom" is really found, the PythonShellScript process doesn't get terminated, even if it is closed using the [Exit] key... (this can be verified using Y-Tasks application) so the application heap eventually gets eaten up till [Out of Memory]...
The same seems to happen for a Synchronous process (without using callback) as well
Is it a bug with the "Service.Contact" process? Any quick workarounds to the problem, or ways to wrap the PyS60 1.4.x contacts module to an asynchronous call?

Thanks for any kind help.

(Otherwise, this scriptext service is working great! creating a Contact list of everyone in DB is much more transparent to the user . as it takes around 1 sec to read through my contacts..)

[raf1hh]

Try isolating the fault by making the sample simpler. First verify that the callback gets actually called, then that all objects are accessible in the callback (for instance the lock object) etc.

Can you test this?

import scriptext
import e32

lock = e32.Ao_lock()
def exit_handler():lock.signal()
appuifw.app.exit_key_handler = exit_handler

def get_list(trans_id, event_id, input_params):
    print "call back was called"


contacts_handle = scriptext.load("Service.Contact", "IDataSource")
event_id = contacts_handle.call('GetList', {'Type': u'Contact', 'Filter':{'SearchVal': u'Tom'}}, callback=get_list)

print "Waiting for the request to be processed!"
lock.wait()
print "App exit!"

[kohchunk]

I tried the shorter version, and the following was printed

Waiting for the request to be processed!
call back was called

First "Exit" press to exit this script prints:

App exit!

And i pressed "Exit" another time to exit the PythonShellScript.
From here, the PythonShellScript is not visible when holding the "App" key, but the process PythonScriptShell[e7881dfa] is still running infinitely when viewed using Y-Tasks.

Another weird (but useful behaviour: Using the long version, if i try to create a listA (of results) in for..loop part of the callbackC1 function, it is executed as a background process and I can access parts of the listA from another functionF1 outside.
ie. both functions callbackC1 and functionF1 are executed simultaneously (interleaved?, since Symbian has only 1 active thread each time)
Is this correct? (This is working great for background loading of contacts though)

I've switched to using the more stable contacts module for now

[ashwinurao]

If the contact "Tom" is really found, the PythonShellScript process doesn't get terminated, even if it is closed using the [Exit] key... (this can be verified using Y-Tasks application) so the application heap eventually gets eaten up till [Out of Memory]...
The same seems to happen for a Synchronous process (without using callback) as well
Is it a bug with the "Service.Contact" process? Any quick workarounds to the problem, or ways to wrap the PyS60 1.4.x contacts module to an asynchronous call?

Did you try to run this script as a standalone application(package using PyS60 application packager) instead of running it from ScriptShell?

[JOM]

Another weird (but useful behaviour: Using the long version, if i try to create a listA (of results) in for..loop part of the callbackC1 function, it is executed as a background process and I can access parts of the listA from another functionF1 outside.
ie. both functions callbackC1 and functionF1 are executed simultaneously (interleaved?, since Symbian has only 1 active thread each time)
Is this correct? (This is working great for background loading of contacts though)

Sounds like it's working just like it's supposed to. Anything else might be a defect

Asynchronous operation runs at background and allows you to do something else, for example show a status or progress note 3/n items handled. Accessing data before callback is called can give you false data. Synchronous operation keeps you waiting until it's done, which might look like the whole app just froze. Might make user wonder, if the device crashed.

Cheers,

--jouni

[kohchunk]

That's cool! Thanks for the tip about the synchronous/asynchronous events.
I'm still struggling with the many events (key event callback, inbox callback, and Ao_lock stuff) in the code, and was confused about how it works together . I thought previously that the Contact request callback works something like canvas.bind callbacks, which are queued when 2 keys are pressed?

About the thread bug: I tried packaging it into a .sis file, and it didn't work also.. (ie the process doesn't get terminated even after it is exited.)