It seems that under Motif2.1 there is a Timer that ends the
drop transfer when it occurs. Even though the
XmNtransferProc is still running. This makes aplications to
`core dump`.
Is there any way to deactivate this timeout if we know that
the XmNtransferProc will be long ?
It seems that this timer does not exist under Motif1.2.
jean-pierre
That should certainly be easy to check; you can modify one of the standard demos or tests to have a transfer procedure that does a long (10 second?) sleep instead of setting data. What does the core dump then show? See elsewhere on this site for how to submit a bug and how to search the database.
But my memory of the code doesn`t show such a timer. There is, however, some bad code that showed up in Motif 2.0, that may be related. Somewhere in DropTransfer.c (?), the code adds a 0-length timeout. The idea is that Xt will handle other events and timers and then execute this timer. However, Xt isn`t supposed to work this way, and the code in fact doesn`t match the spec for how timers are supposed to be implemented. The Xm code depends on an Xt bug, then. In this case, I think what can happen is that the timer is fired immediately by Xt before the matching code, perhaps with the results that you`re seeing. Sorry if I`m fuzzy on the details; it made sense when I found it the first time. The solution was more complicated than simply making the timeout 1ms instead of 0ms, but I don`t remember what I proposed.
When I said a long transfer procedure, I talked about a n-minutes transfer. A very long one, because the user has
to do some manipulations to complete the drag&drop.
I understand that the acceptation of the drop must be fast, and it is. But nowhere in the programming guide it is written that the drop handle has to be fast too.
It is in DropTransfer.c that the core occurs.
there is the call stack given by the core
#0 0x404f5cde in TerminateTransfer (dt=0x8109f10, selection=0xbfffe718) at DropTrans.c322
DropTrans.c322 No such file or directory.
(gdb) where
#0 0x404f5cde in TerminateTransfer (dt=0x8109f10, selection=0xbfffe718) at DropTrans.c322
#1 0x404f5f7a in DropTransferSelectionCB (w=0x80a1818, client_data=0x8109f10, selection=0xbfffe718, type=0xbfffe6f8, value=0x8109fe8,
length=0xbfffe700, format=0xbfffe704) at DropTrans.c469
#2 0x4066c17c in DoLocalTransfer ()
#3 0x4066c210 in GetSelectionValue ()
#4 0x4066c340 in XtGetSelectionValue ()
#5 0x404f5e78 in ProcessTransferEntry (dt=0x8109f10, which=0) at DropTrans.c404
#6 0x404f5fb8 in StartDropTimer (clientData=0x8109f10, id=0xbfffe870) at DropTrans.c492
#7 0x406652c0 in DoOtherSources ()
#8 0x406655b6 in XtAppNextEvent ()
#9 0x403273ae in mtf_show_toplevel ()
#10 0x402b4e6a in uf_show_toplevel ()
#11 0x804c8d2 in tro_init_level2 ()
#12 0x804c4af in main ()
As Motif2.1 use UTM, and not Motif1.2, could it be possible that the timer launched by StartDropTimer is due to UTM?
That`s the code that I was talking about, although you`re not running 2.1.30, judging from the slight line mis-matches between the stack trace and the 2.1.30 code. You may want to try upgrading; clearly, there have been changes in this section of code.
And because the stack trace doesn`t quite match the code, it`s hard to tell what is going on; but that code is reasonably safe except for two dereferences of drag/drop-related data structures, so I expect that one of them is not valid.
In addition, there may be a work-around. Drag-and-drop really isn`t appropriate for such large data transfers, measured either in time (as in an operation that takes a while) or in space (as in an operation that generates massive amounts of data -- although earlier bugs in handling incremental transfers should be fixed).
The user, in any case, is faced with an unresponsive interface during that time. Drag/drop should give the appearance of an interactive display and lively responses.
What you can do, then, instead of generating the data and then transferring it, is to generate other information which will allow your two applications to establish a separate channel of communication. For example, if you know that the two applications are on the same machine -- which may be the case for turnkey systems -- you can transfer the file name in which the second application can find the data. Or, the application can transfer back a private selection name, take the time to generate the data, and regrab the selection as an indication that the data is ready to be retrieved (via XtGetSelectionValue()).
Operations that take a long time are always a problem; in this case, it seems that the problem is exacerbated by having two applications involved. I`m not surprised that there is a problem.
Again, it would also be a good idea to generate a simple example showing the problem.
(Note I did try to find the bug report I referred to, but I wasn`t able to; it may be in the original OSF OT database for pre-bug info.)
And note that I`m not convinced that a long transfer is really the cause of the bug you`re seeing; if it were, you could check http//www.motifzone.com/resources/man/XtSetSelectionTimeout.html and change the value (I think 5000ms is the default). The bug, as I remember it, really had more to do with what gettimeofday() returned inside Xt.
Sorry to follow up the same message three times.
And note that I`m not convinced that a long transfer is really the cause of the bug you`re seeing; if it were, you could check http//www.motifzone.com/resources/man/XtSetSelectionTimeout.html and change the value (I think 5000ms is the default). The bug, as I remember it, really had more to do with what gettimeofday() returned inside Xt.
Sorry to follow up the same message three times.
If I increase this timeout, it seems to work.
Thanks a lot,
jean-pierre