Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

Add signal handling to stream manager #2950

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

glrf
Copy link

@glrf glrf commented Jul 4, 2018

This adds signal handling to the EventLoopImpl in order to add a SIGTERM handler to the stream manager. (See #2947)

I tried to handle signal events similarly to the other events. This resulted in quite a lot of boilerplate code, I am not completely sure this is the right way to go.

Copy link
Contributor

@nwangtw nwangtw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a few simple comments.

However I am not familiar with signal handling. @skanjila might take a look?

return 0;
}

int EventLoopImpl::unRegisterSignal(int sig) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where is this function hooked up?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is not actually used yet. I included it, because other events also have a unregister function and it might be useful sometime in the future.

I can also remove it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kk. It is ok to leave it there to me. Let's see if @srkukarni has any input.

EventLoopImpl ss;

void sigtermHandler(int signum) {
ss.loopExit();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit concerned that if loopExit() is safe to call here.

  • which thread it is running on and if there might be racing condition.
  • if it is possible that loopExit() might get stuck.

Copy link
Author

@glrf glrf Jul 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the sigtermHandler should run the in the same thread as any other callback function and loopExit() directly calls event_base_loopbreak() which I think should be safe to call. Here in the libevent book they call event_base_loopbreak() in a very similar way.

But maybe someone with more experience with libevent could give some input on that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nwangtw - stmgr runs in a single thread. hence loopExit is fine in the context of sigterm handler.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nwangtw - stmgr runs in a single thread. hence loopExit is fine in the context of sigterm handler.

if (event_del(mSignalEvents[sig]->event()) != 0) {
throw heron::error::Error_Exception(errno);
}
delete mSignalEvents[sig];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

safer way is to use a temp var to make sure the object is erased from the map before deleting it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that this is done the same way multiple times in event_loop_impl.cpp (See e.g. unRegisterForRead or unRegisterForWrite).

Should I change it for every unRegsiter* function or should I leave it that way. It would be inconsistent if I would only change the unRegisterSignal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Glorfischi - can you please do those changes for other unRegister events as well?

@kramasamy
Copy link
Contributor

@nwangtw @Glorfischi - is this ready to be merged?

@kramasamy
Copy link
Contributor

@nwangtw - can you please check if this is ok to merge it? @Glorfischi - have you fixed all the feedback.

@glrf
Copy link
Author

glrf commented Jul 14, 2018

Sorry for the delay.

I have a fix ready for one of the feedback, but I'll wait for a response before I push it. See the comment on the unRegister* functions.

As for the ss.loopExit() call. I think this should be fine, but I hoped someone with more experience with libevent could give the ok.

…the event is erased from the map before deleting it.
if (event_del(mSignalEvents[sig]->event()) != 0) {
throw heron::error::Error_Exception(errno);
}
auto* event = mSignalEvents[sig];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need an auto* ? just auto event will be fine, isn't?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yes I think you're right. That * is useless.

@@ -136,8 +176,9 @@ int EventLoopImpl::unRegisterForRead(int fd) {
// cout << "event_del failed for fd " << fd;
throw heron::error::Error_Exception(errno);
}
delete mReadEvents[fd];
auto* event = mReadEvents[fd];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here and other places.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants