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
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.
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.
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.
/ 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
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
Can I destruct every non blocking Stdio.File() using destruct in the destroy() method of my parent object ?
I take it that your callbacks are in that parent object. Yes, you can, but if you do it in another thread you'll get the same race as a set_read_callback call.
What is the problem with making it thread safe ?
o It would give an overhead in Stdio.File that would be unnecessary in most simple applications. o It could be tricky to do without introducing the risk of a deadlock together with other mutexes in the application. I haven't figured out a way for that, at least. o You'll probably have the same race problem anyway on a higher level in your application.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-17 16:52: Subject: Re: Strange things with Stdio.File
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
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
David Gourdelier -
Martin Stjernholm, Roxen IS ＠ Pike developers forum