#3302 threads and "would wait forever" message

obsolete: 8.4.11
closed-wont-fix
Jan Nijtmans
5
2009-06-19
2005-11-15
miguel sofer
No

In unthreaded 8.4 and 8.5, we have the traditional message:

mig@ave:/home/CVS/tcl_SF_clean/unix$ ./tclsh
% vwait a
can't wait for variable "a": would wait forever
%

However, the vwait succeeds in threaded builds.

I'm not sure if this is a bug or not.

Discussion

  • Logged In: YES
    user_id=79902

    Tcl_ThreadQueueEvent allows an arbitrary thread to inject
    events into another arbitrary thread's queue, without being
    a formally declared event source. This makes determining
    that there are no event sources about somewhat difficult to
    say the least...

     
  • It would be nice if we could fix this, but it seems that we can't (other than by removing the "would wait forever" message, which isn't the sort of fix I'd approve of) with reasonable effort as it is too awkward to account for all possible event sources in a threaded build. So, no point keeping this issue open.

     
    • status: open --> closed-wont-fix
     
  • What about counting other threads, and raising that error only if we are alone ?
    IOW, all N-1 others play the role of "suspected event sources"...

     
    • status: closed-wont-fix --> open-remind
     
    • status: open-remind --> closed-wont-fix
     
  • Please answer.

     
  • Jan Nijtmans
    Jan Nijtmans
    2009-06-22

    Well, the fact that dkf put this issue to "WontFix" is an answer ;-)

    Let me put my $0.02
    The problem with your proposed solution is that the second thread
    might not be known to Tcl when the vwait starts. Or maybe the
    event is meant to be triggered from a UNIX signal. So the fact
    that there are no other Tcl threads, doesn't mean that we would
    wait forever.

    Yes, this all is highly theoretical. In this case, I am
    inclined to agree with dkf, but at least it should still be
    documented somewhere......

     
  • Thread not created at vwait time: how could that thread start later, then ?

    UNIX signal:
    (1) not supported in vanilla tclsh;
    (2) should be backed by a registered event source (aren't they in TclX ?)
    (3) Ain't this orthogonal to threads ? How does it behave with TclX in a non-threaded core ?

     
  • Jan Nijtmans
    Jan Nijtmans
    2009-06-22

    > how could that thread start later, then?
    Is there a (portable) way to count threads? If there is, then just
    propose a patch, I wound't have a problem with that. Yes, there
    must be at least one other thread. Or maybe it is even possible
    to create a new thread from within a UNIX signal handler......
    Threads and UNIX signals are tricky.

    There is no fundamental reason for the "WontFix", merely a
    practical one: Someone just needs to put time in it, in order
    to implement a solution that solves more problems than that
    it possibly creates.