nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
1378bb049a
putty-source/callback.c

134 lines
3.1 KiB
C
Raw Normal View History

Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
/*
* Facility for queueing callback functions to be run from the
* top-level event loop after the current top-level activity finishes.
*/
#include <stddef.h>
#include "putty.h"
struct callback {
struct callback *next;
toplevel_callback_fn_t fn;
void *ctx;
};
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
struct callback *cbcurr = NULL, *cbhead = NULL, *cbtail = NULL;
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
toplevel_callback_notify_fn_t notify_frontend = NULL;
Introduce a typedef for frontend handles. This is another major source of unexplained 'void *' parameters throughout the code. In particular, the currently unused testback.c actually gave the wrong pointer type to its internal store of the frontend handle - it cast the input void * to a Terminal *, from which it got implicitly cast back again when calling from_backend, and nobody noticed. Now it uses the right type internally as well as externally.
2018-09-12 08:10:51 +00:00
void *notify_ctx = NULL;
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
void request_callback_notifications(toplevel_callback_notify_fn_t fn,
Introduce a typedef for frontend handles. This is another major source of unexplained 'void *' parameters throughout the code. In particular, the currently unused testback.c actually gave the wrong pointer type to its internal store of the frontend handle - it cast the input void * to a Terminal *, from which it got implicitly cast back again when calling from_backend, and nobody noticed. Now it uses the right type internally as well as externally.
2018-09-12 08:10:51 +00:00
void *ctx)
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
{
notify_frontend = fn;
Introduce a typedef for frontend handles. This is another major source of unexplained 'void *' parameters throughout the code. In particular, the currently unused testback.c actually gave the wrong pointer type to its internal store of the frontend handle - it cast the input void * to a Terminal *, from which it got implicitly cast back again when calling from_backend, and nobody noticed. Now it uses the right type internally as well as externally.
2018-09-12 08:10:51 +00:00
notify_ctx = ctx;
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
}
Add a concept of 'idempotent callback'. This is a set of convenience wrappers around the existing toplevel callback function, which arranges to avoid scheduling a second call to a callback function if one is already in the queue. Just like the last few commits, this is a piece of infrastructure that nothing is yet using. But it will.
2018-05-18 06:22:57 +00:00
static void run_idempotent_callback(void *ctx)
{
struct IdempotentCallback *ic = (struct IdempotentCallback *)ctx;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ic->queued = false;
Add a concept of 'idempotent callback'. This is a set of convenience wrappers around the existing toplevel callback function, which arranges to avoid scheduling a second call to a callback function if one is already in the queue. Just like the last few commits, this is a piece of infrastructure that nothing is yet using. But it will.
2018-05-18 06:22:57 +00:00
ic->fn(ic->ctx);
}
void queue_idempotent_callback(struct IdempotentCallback *ic)
{
if (ic->queued)
return;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
ic->queued = true;
Add a concept of 'idempotent callback'. This is a set of convenience wrappers around the existing toplevel callback function, which arranges to avoid scheduling a second call to a callback function if one is already in the queue. Just like the last few commits, this is a piece of infrastructure that nothing is yet using. But it will.
2018-05-18 06:22:57 +00:00
queue_toplevel_callback(run_idempotent_callback, ic);
}
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
void delete_callbacks_for_context(void *ctx)
{
struct callback *newhead, *newtail;
newhead = newtail = NULL;
while (cbhead) {
struct callback *cb = cbhead;
cbhead = cbhead->next;
Add a concept of 'idempotent callback'. This is a set of convenience wrappers around the existing toplevel callback function, which arranges to avoid scheduling a second call to a callback function if one is already in the queue. Just like the last few commits, this is a piece of infrastructure that nothing is yet using. But it will.
2018-05-18 06:22:57 +00:00
if (cb->ctx == ctx ||
(cb->fn == run_idempotent_callback &&
((struct IdempotentCallback *)cb->ctx)->ctx == ctx)) {
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
sfree(cb);
} else {
if (!newhead)
newhead = cb;
else
newtail->next = cb;
newtail = cb;
}
}
cbhead = newhead;
cbtail = newtail;
Fix a newly introduced segfault in callback.c. Colin Harrison points out that commit c31e3cd43 was less cautious than it should have been: when delete_callbacks_for_context nulls out the 'next' pointer in the new tail element of the callbacks list, it should only do so if there _is_ a new tail element. If the list has just become empty, that won't work very well!
2018-10-25 17:34:19 +00:00
if (newtail)
newtail->next = NULL;
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
}
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
void queue_toplevel_callback(toplevel_callback_fn_t fn, void *ctx)
{
struct callback *cb;
cb = snew(struct callback);
cb->fn = fn;
cb->ctx = ctx;
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
/*
* If the front end has requested notification of pending
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
* callbacks, and we didn't already have one queued, let it know
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
* we do have one now.
*
* If cbcurr is non-NULL, i.e. we are actually in the middle of
* executing a callback right now, then we count that as the queue
* already having been non-empty. That saves the front end getting
* a constant stream of needless re-notifications if the last
* callback keeps re-scheduling itself.
*/
if (notify_frontend && !cbhead && !cbcurr)
Introduce a typedef for frontend handles. This is another major source of unexplained 'void *' parameters throughout the code. In particular, the currently unused testback.c actually gave the wrong pointer type to its internal store of the frontend handle - it cast the input void * to a Terminal *, from which it got implicitly cast back again when calling from_backend, and nobody noticed. Now it uses the right type internally as well as externally.
2018-09-12 08:10:51 +00:00
notify_frontend(notify_ctx);
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
if (cbtail)
cbtail->next = cb;
else
cbhead = cb;
cbtail = cb;
cb->next = NULL;
}
Fix startup hang in Unix file transfer tools. This seems to be a knock-on effect of my recent reworking of the SSH code to be based around queues and callbacks. The loop iteration function in uxsftp.c (ssh_sftp_do_select) would keep going round its select loop until something had happened on one of its file descriptors, and then return to the caller in the assumption that the resulting data might have triggered whatever condition the caller was waiting for - and if not, then the caller checks, finds nothing interesting has happened, and resumes looping with no harm done. But now, when something happens on an fd, it doesn't _synchronously_ trigger the follow-up condition PSFTP was waiting for (which, at startup time, happens to be back->sendok() starting to return TRUE). Instead, it schedules a callback, which will schedule a callback, which ... ends up setting that flag. But by that time, the loop function has already returned, the caller has found nothing interesting and resumed looping, and _now_ the interesting thing happens but it's too late because ssh_sftp_do_select will wait until the next file descriptor activity before it next returns. Solution: give run_toplevel_callbacks a return value which says whether it's actually done something, and if so, return immediately in case that was the droid the caller was looking for. As it were.
2018-05-24 15:54:16 +00:00
int run_toplevel_callbacks(void)
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
int done_something = false;
Fix startup hang in Unix file transfer tools. This seems to be a knock-on effect of my recent reworking of the SSH code to be based around queues and callbacks. The loop iteration function in uxsftp.c (ssh_sftp_do_select) would keep going round its select loop until something had happened on one of its file descriptors, and then return to the caller in the assumption that the resulting data might have triggered whatever condition the caller was waiting for - and if not, then the caller checks, finds nothing interesting has happened, and resumes looping with no harm done. But now, when something happens on an fd, it doesn't _synchronously_ trigger the follow-up condition PSFTP was waiting for (which, at startup time, happens to be back->sendok() starting to return TRUE). Instead, it schedules a callback, which will schedule a callback, which ... ends up setting that flag. But by that time, the loop function has already returned, the caller has found nothing interesting and resumed looping, and _now_ the interesting thing happens but it's too late because ssh_sftp_do_select will wait until the next file descriptor activity before it next returns. Solution: give run_toplevel_callbacks a return value which says whether it's actually done something, and if so, return immediately in case that was the droid the caller was looking for. As it were.
2018-05-24 15:54:16 +00:00
Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. [originally from svn r10040]
2013-09-15 14:05:31 +00:00
if (cbhead) {
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
/*
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
* Transfer the head callback into cbcurr to indicate that
* it's being executed. Then operations which transform the
* queue, like delete_callbacks_for_context, can proceed as if
* it's not there.
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
*/
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
cbcurr = cbhead;
cbhead = cbhead->next;
Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. [originally from svn r10040]
2013-09-15 14:05:31 +00:00
if (!cbhead)
cbtail = NULL;
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
/*
* Now run the callback, and then clear it out of cbcurr.
*/
cbcurr->fn(cbcurr->ctx);
sfree(cbcurr);
cbcurr = NULL;
Fix startup hang in Unix file transfer tools. This seems to be a knock-on effect of my recent reworking of the SSH code to be based around queues and callbacks. The loop iteration function in uxsftp.c (ssh_sftp_do_select) would keep going round its select loop until something had happened on one of its file descriptors, and then return to the caller in the assumption that the resulting data might have triggered whatever condition the caller was waiting for - and if not, then the caller checks, finds nothing interesting has happened, and resumes looping with no harm done. But now, when something happens on an fd, it doesn't _synchronously_ trigger the follow-up condition PSFTP was waiting for (which, at startup time, happens to be back->sendok() starting to return TRUE). Instead, it schedules a callback, which will schedule a callback, which ... ends up setting that flag. But by that time, the loop function has already returned, the caller has found nothing interesting and resumed looping, and _now_ the interesting thing happens but it's too late because ssh_sftp_do_select will wait until the next file descriptor activity before it next returns. Solution: give run_toplevel_callbacks a return value which says whether it's actually done something, and if so, return immediately in case that was the droid the caller was looking for. As it were.
2018-05-24 15:54:16 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
done_something = true;
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
}
Fix startup hang in Unix file transfer tools. This seems to be a knock-on effect of my recent reworking of the SSH code to be based around queues and callbacks. The loop iteration function in uxsftp.c (ssh_sftp_do_select) would keep going round its select loop until something had happened on one of its file descriptors, and then return to the caller in the assumption that the resulting data might have triggered whatever condition the caller was waiting for - and if not, then the caller checks, finds nothing interesting has happened, and resumes looping with no harm done. But now, when something happens on an fd, it doesn't _synchronously_ trigger the follow-up condition PSFTP was waiting for (which, at startup time, happens to be back->sendok() starting to return TRUE). Instead, it schedules a callback, which will schedule a callback, which ... ends up setting that flag. But by that time, the loop function has already returned, the caller has found nothing interesting and resumed looping, and _now_ the interesting thing happens but it's too late because ssh_sftp_do_select will wait until the next file descriptor activity before it next returns. Solution: give run_toplevel_callbacks a return value which says whether it's actually done something, and if so, return immediately in case that was the droid the caller was looking for. As it were.
2018-05-24 15:54:16 +00:00
return done_something;
Only run one toplevel callback per event loop iteration. This change attempts to reinstate as a universal property something which was sporadically true of the ad-hockery that came before toplevel callbacks: that if there's a _very long_ queue of things to be done through the callback mechanism, the doing of them will be interleaved with re-checks of other event sources, which might (e.g.) cause a flag to be set which makes the next callback decide not to do anything after all. [originally from svn r10040]
2013-09-15 14:05:31 +00:00
}
int toplevel_callback_pending(void)
{
New facility for removing pending toplevel callbacks. This is used when you're about to destroy an object that is (potentially) the context parameter for some still-pending toplevel callback. It causes callbacks.c to go through its pending list and delete any callback records referring to that context parameter, so that when you destroy the object those callbacks aren't still waiting to cause stale-pointer dereferences.
2017-11-25 17:17:21 +00:00
return cbcurr != NULL || cbhead != NULL;
Add a general way to request an immediate top-level callback. This is a little like schedule_timer, in that the callback you provide will be run from the top-level message loop of whatever application you're in; but unlike the timer mechanism, it will happen _immediately_. The aim is to provide a general way to avoid re-entrance of code, in cases where just _doing_ the thing you want done is liable to trigger a confusing recursive call to the function in which you came to the decision to do it; instead, you just request a top-level callback at the message loop's earliest convenience, and do it then. [originally from svn r10019]
2013-08-17 16:06:08 +00:00
}
Reference in New Issue Copy Permalink