Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
The read callback registered in the Stdio.File object has become zero in some way without Stdio.File knowing about it. If you set it to zero through set_read_callback or similar, it will deregister the internal wrapper callback __stdio_read_callback correctly and it won't happen.
I set 0 throught set_read_callback.
A common cause for this is that the object your callbacks are in has been destructed while the Stdio.File object still is in use by the backend.
Can I destruct every non blocking Stdio.File() using destruct in the destroy() method of my parent object ?
Another possibility is that you call set_read_callback(0) in another thread when the backend thread just has called __stdio_read_callback.
Stdio.File isn't thread safe, and I'm not sure it should be. There are some attempts to make it thread safe in 7.4 and later through the internal functions _disable_callbacks and _enable_callbacks, but afaics they won't work reliably.
What is the problem with making it thread safe ?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-17 11:06: Subject: Strange things with Stdio.File
Hi list,
I am have some problems with Stdio.File which looks quite the same telling about the attempt to call the NULL-value when using non blocking I/O:
Attempt to call the NULL-value Unknown program: 0(0,"* OK [CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT] Courier-IMAP ready. Copyright 1998-2003 Double Precision, Inc. See COPYING for distribution informatio"+[5]) /usr/local/pike/7.2.512/lib/modules/Stdio.pmod/module.pmod:692: Stdio.File("socket", "localhost:143", 777 /* fd=-1 */)->__stdio_read_callback()
Attempt to call the NULL-value Unknown program: 0(0,"421 Error: timeout exceeded\r\n") /usr/lib/pike/7.2.526/lib/modules/Stdio.pmod/module.pmod:692: Stdio.File("socket", "127.0.0.1:10026", 777 /* fd=35 */)->__stdio_read_callback()
Do you know what these mean ? FYI I use Pike 7.2.512 and 7.2.526.
/ David Gourdelier
/ Brevbäraren