On 8 Aug 2000, Jiang Wu wrote:
> After spending some hours in gdb tracing the program, it seems that the problem
>occurs in tclUnixChan.c:FileInputProc() line 380: *errorCodePtr = errno;
>
> 1 byte is written to a non-blocking Tcl file channel. Then 1 byte is successfully
>read from the channel. Then Tcl calls FileInputProc() again to read more. There is
>no more data in the channel, so the call at tclUnixChan.c, line 376
>
> bytesRead = read(fsPtr->fd, buf, (size_t) toRead);
>
> returns -1. However, for some reason, the system variable "errno" is always 0, not
>EAGAIN as expected by the caller function. This causes the caller function
>(tclIO.c:GetInput(), line 4865) to loop forever calling FileInputProc() over and over
>again.
>
> I have not determined what caused the problem with "errno".
> The Tcl library is loaded into a JVM at this point. So the
> process is running in multi-threaded mode. The Tcl library
> used is non-threaded, version 8.3.1. Can there be something
> bad about using "errno" from multiple threads?
Under Solaris, errno becomes a function that returns a thread
local variable when you compile with -D_REENTRANT. You compiled
this version of Tcl with threads support, right?
> Another strange thing if I run the same Java program on a smaller
> example, then it seems to work OK. When the error does happen,
> there are many threads in the process.
Sounds like a race condition dealing with ERRNO. I wonder if
Tcl is not getting compiled without -D_REENTRANT or something.
That seems unlikely. Tcl Blend just uses the CFLAGS set
by Tcl.
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
