This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hmm? So there's only one token for all notification types?+/* Asynchronous signal handle registered as event loop source for when >+ the remote sent us a notification. The registered callback >+ will do a ACK sequence to pull the rest of the events out of >+ the remote side into our event queue. */ >+ >+static struct async_event_handler *remote_async_get_pending_events_token;
What if two notifications of different types are pending?
>+ >+/* A stop notification. */ >+ >+struct notif_stop >+{ >+ struct notif base; >+ /* The list of already fetched and acknowledged events. */ >+ QUEUE (notif_reply_p) *ack_queue; >+};I'm confused on the abstraction layers here. So other notifications won't need a queue? How do they work then? And then, if only stops need it, why do we need to stuff it in a new type, and come up with "struct notif_stop" at all? This seems to be related to the comment in notif.c that talks about stop replies being different. Then, it seems we're just adding layers for no no real generalization. I'd rather just leave the queue global as it was, and make notif_packet_stop a plain struct notif. Make struct notif|notif.c as simple as possible, a layer to build uppon, with no knowlege of the sub types of notifications.
struct notif_postmortem { struct notif base; /* The list of already fetched and acknowledged events. */ QUEUE (notif_reply_p) *ack_queue; };
No need for the cast. See XMALLOC's definition.>- { >- VEC_free (cached_reg_t, r->regcache); >- xfree (r); >- } >+ VEC_free (cached_reg_t, r->regcache); > } > >-/* Discard all pending stop replies of inferior PID. If PID is -1, >- discard everything. */ >+static struct notif_reply * >+remote_notif_alloc_reply_stop (void) >+{ >+ struct notif_reply *r = (struct notif_reply *) XMALLOC (struct stop_reply);
-- Yao (éå)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |